Planning an Importable TinyGo

[soypat]

Most TinyGo packages and tools could be usable by other Go projects if only they were designed for this.

• device package is a TinyGo stdlib and prevents other projects from using TinyGo packages like the pio package: Support for wifi embeddedgo/pico#1
• volatile similarly is a TinyGo stdlib. Planning a common package/design could make hardware packages reusable in the ecosystem
• machine is notably THE hardware package. Since it makes use of both device, volatile and is used closely with the runtime package. That said, there is no reason it could not be importable if it were redesigned from the ground up.

This discussion is to put all these ideas on how to improve our ecosystem by packaging these HALs so that there is one unified embedded API that can be used across package and project boundaries i.e: Embedded Go, TamaGo and other projects.

As a thought provoker, the runtime package HAL is in the process of happening in upstream Go: golang/go#73608

If this issue gets accepted then we could even think of having packages that package runtime logic i.e: tinygo-org/schedulers and tinygo-org/gc