Start of work on matrix codegen

Works for C code only, with input and input/output args of matrices.
Expression to be codegen'ed must be an Eq(MatrixSymbol, Matrix). Still
need to work through codegen code to see if there is an easier (less
hackish) way, but it currently "works".
Continued work on Matrix codegen support

Now supports automatic output variable creation for Matrices not
originally wrapped in an `Eq`. This means that the following now works:

    mat = Matrix([a, b, c])
    codegen(('mat', mat), 'c', 'mat)

Also did some code cleanup to prior work on matrices.
Start of refactor to codeprinter and ccode

Start of refactor to codeprinters to make adding new features simpler.
The main purpose behind this is to make support for matrices and matrix
expressions easier, and remove bugs in Piecewise and looping.

- Added Assignment node, to represent assignment rather than Equality
  (which should be used for equality testing, resulting in a bool).
- Refactored ccode `doprint` method to move most of the control flow to
  a _print_Assignment method, called like all other print methods by the
  _print method in Printer. This makes more sense, and sticks with the
  original design of the Printer class.
- Some variable name cleanups to improve readability of the CodePrinter
  class.
Refactored fcode to be more like ccode

Refactored fcode similar to how ccode was changed in the last commit.
Also changed doprint to accept assign_to as a kwarg, as ccode does,
rather than store it as a setting.
Added support for matrices in Fortran

Fortran code printing now supports 2 dimensional arrays. Also added
(possible) efficiency improvement by reordering declaration order of C
code array elements to be in-memory order. gcc probably optimizes this
already, but it was an easy fix.
Continuation of Codegen Refactor

- Moved common methods onto CodePrinter class
- We now check if either the lhs or rhs of an expression has IndexedBase
  objects to see if loops are needed. This is necessary because
  sometimes the accumulator isn't an Indexed Object. There were two
  thoughts on how to set this up:

1. Call _doprint_a_piece (now _doprint_loops) on *all* Assignment
   expressions:
    - Expressions w/o loops: 2 tree traversals before being printed
    - Expressions w/ loops: 2 tree traversals before being printed

2. Check for IndexedBase in lhs first, then rhs:
    - Expressions w/o loops: 1 tree traversal before being printed
    - Expressions w/ loops: 3 tree traversals before being printed
      (worst case. Most cases will be only 2).

Note that most Indexed expressions tend to be short and concises, as
well as have a lhs which contains Indexed objects (will result in *fast*
method call, because lhs trees are small). In contrast, most users do
not use Indexed, and many expressions are rather large. Hence it is more
beneficial for the user to be cheaper on loopless expressions, while
increasing the worst-case time for looped expressions (most looped
expressions will have a negligible time increase).
jscode fixes: refactor and matrix support

Continuation of the codegen refactor. jscode now in same format as ccode
and fcode. jscode now also supports matrices.
More work on Refactoring of CodeGen stuff:

- Moved all common methods into CodePrinter
- Added methods that need to be defined by anything subclassed from
  `CodePrinter` to `CodePrinter` with a `NotImplementedError`. This
  should help anyone out looking to create a new code printer, as it
  shows what needs to be defined by the subclass so that everything just
  *works*
- Small fix to the mathematic printing so it has it's own doprint method.
  I don't know anything about mathematica. This keeps everything the same
  as before for this refactoring.
- Small formatting cleanups
Rewrite of inline conditional codegen

Now Piecewise lacking a default condition (i.e. an (expr, True) term)
will throw an error. This is because without such a statement, the
generated code may not return anything. Other options were to return NaN
in such a situation, but this was turned down due to lack of support by
all languages/compilers, and that this is unexpected behavior. Added
tests for the conditional printing.
Rewrote Assignment, added tests

Rewrote `Assignment` operator to subclass Relational, not Equality. This
reduces object creation time, allowed more types to be used as the rhs,
and makes more sense in the end. Added tests for Assignment. This class
should probably go in a different file, but is in codeprinter for now.

Added tests for matrix code printing to ccode, fcode and jscode.
Codeprinting: bugfixes

- Fixed formatting to work with python 2.6
- Fixed error in immutable eval_Eq
- Added test for Assignment in test_args
Classification of nonlinear sysode for 1st order 3 eq

This commit has the method to classify nonlinear system of 3 ODEs of first order. It contain six type of equation which considered here.
method for 3 type of 3 nonlinear sysode of 1st order

This contains definition of sysode_nonlinear_3eq_order1 and definition for solving three types of 3 nonlinear system of ODEs of first order.
nonlinear sysode 3eq order1 type4
Added type5 and few test cases
Updated tests
Updated syntax of dict values
corrected list of solve output
docs of nonlinear sysode of 3 eq 1st order
Continuation of code printing refactor

- Added improved docstrings to fcode, ccode, and jscode
- Standardized implementation of all three code printing functions, they
  now all take the same kwargs (except for standard and source_format,
  which are fortran specific).
- Standardized implementation of Function printing, moved this to
  codeprinter. There was a bug in that some functions that weren't
  standard C/Fortran/JS were getting through without being marked. This
  was because of the old method of "unless it's stated to be bad, it's
  good". The new printing works the opposite: only functions that are
  known to be standard are whitelisted. This catches the issues in a
  much more standard and clean way, and allows for reuse of the
  print_Function implementation.
- As part of standardizing Function printing, the fix for #6814 was
  changed. Previously we were printing `log(10d0)` for `log(10)` in
  fortran, because this function only accepts floats. The new
  implementation evaluates this to the required precision (default 15)
  in sympy, and just prints a number. If the function doesn't evaluate
  fully (suppose atan2(2, x) -> atan2(2.0000, x)), then the numeric
  constants are still printed as doubles, so everything works fine.