Decide how to follow the latest MicroPython

Today, our build process build MicroPython using the lastest state of master of the MicroPython repository. This is great, because it suggests that our code (as exercised by our tests) works with the very latest MicroPython.

However, or when the MicroPython makes changes to their build process, it can break our build (as it did, see #81).

Perhaps we can find a better way to "track" or "follow" the latest MicroPython, while still retaining control over our build process.

Likely acceptance criteria of any improvement:

• Keeps our build working, even when the MicroPython project makes changes to their build process.
• Allows us to choose when to adapt our build process to the latest MicroPython approach
• Keeps it easy (or automated?) to keep our build close to the latest MicroPython
• Keep some way (even if limited to a local machine) to run against the very latest MicroPython to test/fix our build process.

No files or tests are named. Start by reviewing the current MicroPython build process and issue #81 to understand how upstream changes can break it. A solution is done when it pins or otherwise controls the build, supports deliberate updates, keeps the normal build stable, and preserves a way to test against upstream master.