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.

I agree with this.  How would you feel about having a strategy of first looking for an environment variable if one is set and second checking if the executable is in the PATH?  If neither of the two works then we could raise an exception.  That would allow for vagrant to set up the environment variables correctly but also mean that people wouldn't have to pollute their environment variables with lots of random definitations if they didn't want to use vagrant