Renamed the programming language to Mu

As with most latin letters, there is already a programming
language named V. V was the temporary name until something else
was though of.

The name Mu was thought of for the programming language due to the
target platforms being microcontrollers, sometimes written a uc using
the greek character mu. Mu is also the japanese character for none.
Entertainingly, it is also the sound a cat makes. It is also a
convenient name in that it only uses two letters and is not confusing
to pronounce.

Additionally some naming things were cleaned up. An underscore is
used whenever Mu is used as a prefix for consistency and some var
functions have dropped the var prefix for cleanliness when they
probably won't clutter the namespace. A single M character is used
when cleaner or being merged with another prefix.
Added correct handling for constant variables

No true reference count should ever equal 0. This lets
a check for 0 be performed to prevent faulting when the
reference counter is in the rodata segment. The memory
will still have to be loaded (possible missing a cache) but
this only hurts the (hopefully) uncommon case of const variables.
Made several changes to Mu's header structure and prefixes

Mu now uses a preprocessor template in its header files to limit
the amount of definitions introduced with each include. This allows
more flexibility with prefixes since most internal can avoid being
included.

Also, mu.h was introduced as a central location for defining compiler
specific definitions and other common definitions.

Additionally, the makefile now builds dependency files for header files.
Simplified error handling by intentionally allowing memory leaks

Error handling is very annoying to implement correctly, especially
in a language without true garbage collection that uses C's own
stack for execution. However, in a correctly functioning program,
true errors should not be expected. To simplify the design of the
language and assumption made about the C runtime, Mu will simply
ignore memory leaks created when errors are propagated.

To handle errors you will be able to register an error handler in
the Mu runtime, or simply check the return of a call to the pcall
function. No memory will be cleaned up and if the program continues
this will be lost forever. This has the nice side effect of
significantly simplifying error handling and memory management.

To make this scheme for useful, I may add a voluntary garbage
collection function in the future.
Fixed an issue in error handling related to nested functions

For longjmp to work correctly, the setjmp call must not be in a
function that has returned. This is pretty unfortunate for writing
a wrapper function and requires a macro. This has been wrapped up
in an exception like macro which leaves room for other mechanics
such as c++ exceptions.
Implemented stand-alone intepreter

The file mu.c implements a stand-alone interpreter which supports
running command line strings, executing files, and can be run
interactively.

There is a slight issue with Mu's grammar that makes the interactive
interpreting a bit wonky. In Mu statements and expressions are
completely seperated when parsing. This seperation is necessary to
prevent ambiguities that happen when not all operators are known.
For example "x >= 2" could be interpreted as "x = x > 2".
Unfortunately, it makes the most sense for interactive input to be
parsed as expressions, however this prevents a number of operations
such as assignments.

The current solution is to attempt expression parsing and if that
fails switch to statement parsing. This currently has an issue with
memory leaks but shouldn't be to hard to fix. Unfortunately this isn't
full-proof; expressions such as "x = 2" still parse as an expression
and it isn't until the operator "=" is lookuped that it fails.
A workaround for this is to use "let x = 2" which correctly drops down
to statement. To force the original behaviour, the statement can also
be forced like so: "{ x = 2 }". Unfortunately, without modifying the
grammar significantly, I believe this is the best solution currently.

Other options included defaulting to statement parsing and requiring
and explicit return to force expressions: "return x + 2". To make this
less annoying, the hardcoded operator "->" was added as an alternative
to return for statements. This operator was kept around as it leads to
a very nice lambdaish function declaration: "fn() -> 2".