[WIP] Octave/Matlab codegen and code printing

I'm working on Octave/Matlab code printing and codegen support.

TODO:

 - [X] Octave code printer (functional, still work to do)
 - [x] Octave codegen
 - [x] Lists
 - [X] Matrix printing
 - [x] Matrix output from codegen
 - [x] codegen: assert filename and function name match, this should be true for the first function in a file.
 - [x] multiple functions per file tested.
 - [ ] multiple functions per file documented scope of results.
 - [X] Logical ops
 - [x] Logical, `True`/`False`
 - [x] Tests, based on C/Fortran tests.
 - [x] Piecewise support
 - [ ] Comment headers to appear after the function prototype line.
 - [X] Use vectorized elementwise operations, e.g., `.*`, `.^`, (unless we know a Matrix is involved?)
 - [x] More special cases for `.*` and `.^`
 - [X] Indenting
 - [ ] deal gracefully like C/Fortran with "not supported"...
 - [X] Is superclass `CodeGen` a bit too C/Fortran specific?  mathematica.py
       was a bit thinner, but is for code printing, not codegen.  Seems it will be ok, especially after @jcrist's recent changes.
 - [X] loop structures.  At least for now, we don't attempt to "vectorize" these.
 - [ ] Fix ordering of outputs.  Codegen sometimes puts in alphabetical order (when they have names via `Eq(name, rhs)`?)  I think they should go in the order I provide them in the `(name, [expr1, expr2, expr3])` list.  If I want to some autosorting, give set or other unordered datastructure?  Inputs should be alphabetically sorted unless the user specifies an order.
 - [ ] Single-statement/single line support?  This is important for generating "handle functions", e.g., [https://github.com/cbm755/octsympy/blob/master/inst/%40sym/matlabFunction.m] as opposed to .m files.  Currently everything is inline.  but I haven't tested tensors yet.

Comments/help very welcome!
What this does is create a `MatrixSymbol` with the same dimensions as the matrix to be returned, to use as the rhs of an Assignment, and also as an output argument. It *is* language specific, but with the current structure must be implemented here. When I did the refactor, I left most of this stuff alone, with the intent to go back later and clean it all up. It would be swell if you could take care of this, as I'm rather busy with research work right now...

The best option (I think) would be to move the magic `Routine` init stuff to some routine initialization factory, that also takes in the language. This would be called by `codegen` to get a `Routine` with the desired properties for the specified language. I'd call it `routine`, and it should have the same args as `Routine` currently does, as well as a language kwarg (default to 'Fortran'). The `__init__` for `Routine` should then only take the args and create the object, no implicit type changes (creation of arguments, results, etc...) these should be passed in explicitly only.

> If its important, please provide a test for C/Fortran that fails without it!

Good catch. There are no codegen tests for matrices, should add one. This would fail without it.