Workflow for avr build

[brentfpage]

(Following up on some of the discussion in #381.)
This PR:

• has lots of commits but they're mostly trial-and-error on single lines. I'll reduce it to ~5 commits and do another PR in the event that the code gets merged.
• adds a workflow (avr.yml) for the firmware
• makes several edits to the firmware source code to make it compatible with the avr workflow's version of avr-gcc (changes are elaborated on in added Makefile for firmware #369 )
• makes edits to continuous.yml:
  • adds a firmware compilation job
  • adds support for the mac build scheme described in the bullet below
• revises mac.yml so that:
  • when mac.yml is called by continuous.yml, the firmware .hex asset produced by continuous.yml is packaged into the mac desktop interface
  • when mac.yml is called in some other context, the firmware .hex asset produced by the most recent call to continuous.yml is packaged into the desktop interface

The versioning is centralized, but not automatic. Namely, the current version of the firmware has to be set in a repository-wide variable, AVR_VER, under (repo home)->settings->secrets+variables->actions->variables->(repository variables). In the fork, AVR_VER=0x0007. At compile time, this variable gets injected:

• into AVR_Code as the macro FIRMWARE_VERSION_ID, which previously was defined in AVR_Code/globals.h
• into the desktop interface as the macro EXPECTED_FIRMWARE_VERSION, which previously was defined in Desktop_Interface/genericusbdriver.h

It would be nicer to have AVR_VER defined in some location like continuous.yml instead, but it needs to be available to mac.yml when that workflow is called individually. I don't know of any other place to define AVR_VER where it would be available to both workflows.

Also, the inclusion of the version number in the .hex file names has been retained, so they are, e.g., labrafirm_0007_0{1 or 2}.hex. To me, this is worthwhile because then the firmware that's packaged into a given release can be very easily determined.

If we decide to go forward with this approach, extending it to encompass the android, linux, and windows builds I think would be straightforward.

[mi-hol]

@brentfpage I like the approach documented above and would approve it.
With the number of changes a real review seems impossible though.

Lets see how other maintainers react.

The is only a minor nit pick

Namely, the current version of the firmware has to be set in a repository-wide variable, AVR_VER

I'd suggest to change name of variable from AVR_VER to AVR_FIRMWARE_VERSION so its purpose is completely self explanatory

[brentfpage]

Split into #404 and #405