Convert pic24 build system to use scons and make momo tool usable

This PR raplaces rake with an scons based build system for pic24.  All of the pic24 modules should compile now with the new build system.  There are still two outstanding issues:
- [ ] unit testing is not yet complete.  I built a simulation framework to handle the sim30 and gpsim programs in a generic way but it's not yet finished.  
- [ ] Compiling an application on pic24 does not check for changes to shared files and recompile if the library has changed.  This requires implementing better dependency scanning, which is well-supported by scons but not yet implemented into the build system.

### Build System Usage
To build pic24 modules, use the same command as for pic12 projects:
```shell
$ momo build
```
### MoMo tool
I have added a shell to the MoMo tool and am including it in this PR mainly because it will be useful for demos in Spain.  Basically, the momo tool takes command line arguments and maps them to python functions via decorator annotations on the functions so that it knows how to convert the parameters to the appropriate types.  If the return value from the function is a context type object, i.e. it has annotated routines that can be run, this context becomes the scope of the next call.  If the command line passed to MoMo is either empty of ends in a context object, a shell is opened and commands are allowed until 'quit' is entered or ctrl-D is sent to indicate and EOF.

Example help usage:
```shell
$ momo
(root) help
root

Defined Functions:
 - controller(string serial='')
 - HexFile(path source, integer wordsize, integer filewords, integer skip=1, integer cutoff=65535)

Builtin Functions
 - quit: quit the momo shell
 - help [function]: print help information about the current context or a function
 - back: replace the current context with its parent

(root) 
```
The same python annotations are used to build help documentation for all of the functions you can call from momo.

Interesting.  I agree with the thinking here.  I can move the per module settings into each module's folder in a separate configuration file.  There are some settings that are global to a chip family though.  For example, on pic12, it's really important that everybody have the same definitions for what rom page the application modules start on, what MIB version to say they were compiled for etc.  How would you propose we handle those types of settings?