Use micropython from new build location during build

[wnienhaus]

The MicroPython project changed their CI scripts slightly, which resulted in the unix port binary being output to a subdirectory (build-standard) instead of the current directory as before. This broke our build process.

This commit updates our build script to search for the micropython binary in the correct subdirectory.

Fixes #81

[wnienhaus]

As a side note, I wondered if we should lock ourselves to a specific tag/version of MicroPython in our build, to avoid breaking our build, when the Micropython project makes similar changes in the future.

On the other hand it's nice knowing that our code works with the latest MicroPython.

Then again, by locking to a specific version and manually changing this every so often, it would prevent the build from breaking at an inconvenient time (when we might not have time to fix it), and instead let us choose when to change version and deal with the potential issues.

@ThomasWaldmann - any experience/suggestion on which would be the better approach?

[mattytrentini]

How about tagging releases in lock-step with MicroPython releases? And follow MicroPython master on this master?

[wnienhaus]

@mattytrentini Hmm. Not sure I fully understand. Do you mean that we should tag this repo and create a release, every time MicroPython has a release, whether we had any changes or not?

And should we maintain 2 branches, one master and one for releases, so we can follow micropython's master from our master branch, and follow the specific MicroPython branch we want for each release in our release branch?

It feels a bit cumbersome, but likely I am overcomplicating it in my head, and you had something much simpler in mind?

[wnienhaus]

@mattytrentini I created an issue to deal with following MicroPython releases vs our build process (#83), to tackle that topic there, while I can so long merge this PR as is.