Adding basic precedence handling.

Haven't added handling for associativity or UnaryOps yet, but this pasts our two meager tests.  I'll definitely be adding some more test cases.  However I wanted to get your opinion on the logic.  Mainly the subclassing for precedence.  This eliminates the need for a separate precedence module.  No real benefits or downsides that I can think of, maybe you have some insights if it's a better idea to keep it separate (would it ever be used outside of the context of operators?).

Commit message below
----
nodes.py
* Made all Ops subclasses of a class that intializes it's precedence
  and associativity.  This moves the logic out of the precedence module,
  but I think it makes sense as it makes our ops better encapsulated.
  This equates to less imports, as well as hopefully easier handling of
  implementation changes further on.
* Added get_precedence() function to Ops which returns there precedence,
  assumes currently that all Ops have a field self.precedence with a
  valid value, i.e. no error checking.  Not sure if we should handle
  errors, if we assume that only we are creating Op subclasses then I
  think it's safe to assume that self.precedence should exist.
* Added get_associativity(), similar logic for above.

codegen.py
* Added __visit_with_precedence(self, prev_prec, node).  works by
	calling the normal visit on the node, but then checks if the child
	node is a BinaryOp.  If it is, then compare precedences and adds if
	parantheses are needed.  Currently only called by visit_BinaryOp.

TODO:
* Handle associativity
* Handle UnaryOps