sympy.physics.quantum.pauli

This pull request contains a few minor fixes for the sympy.physics.quantum, and a new module for pauli operators, like sigma x, sigma y, sigma z, and the annihilation and creation operators sigma minus and sigma plus.

The pauli sigma operators are of course a special case of the angular momentum spin J operators, but I think they are deserve operator classes of their own because they are so commonly used. I have been looking at ways of making the new pauli operator classes subclasses of spin J classes, but I found that there was no advantage in doing that, because I had to reimplement all the methods and add new ones. However, earlier this summer when I discussed the  sympy.physics.quantum.fermion and sympy.physics.quantum.boson modules with @ellisonbg I also mentioned that I had worked a bit on these pauli operator classes and he recommended asking @flacjacket for advise and discussion on how these pauli operator classes could be related to the existing spin J operator classes.

So, @flacjacket, if you could have a look at this PR and give comments I would be very grateful. Also @ellisonbg  and @certik might be interested in having a look.

Here are a few ipython notebook that demonstrates a few applications of the new pauli operators implemented in this PR:

http://nbviewer.ipython.org/github/jrjohansson/sympy-quantum-notebooks/blob/master/lecture-sympy-quantum-two-level-system.ipynb

http://nbviewer.ipython.org/github/jrjohansson/sympy-quantum-notebooks/blob/master/lecture-sympy-quantum-atom-cavity.ipynb

http://nbviewer.ipython.org/github/eunjongkim/reproduced-papers/blob/master/Reproduce-PRA-80-033846-2009-Zueco.ipynb
I agree that it is very convenient and intuitive. However there are a still a number of problems:

* Overriding `__mul__` like this has a ton of problems. Basically it only works in really simple situations where the operator precedence ends up matching that needed to trigger this logic. When we were building sympy.quantum the first time we spent *weeks* trying to get custom `__mul__` methods to work well. It is just not possible with the current design on sympy. Based on this experience, we decided that it was much better, and less confusing to users, to only do simplifications that were reliable and consistent always. That is why you won't find any other `__mul__` logic in `sympy.quantum` and I don't have any plans on changing that until the design of sympy changes.
* There are times when I am working with sympy and I absolutely want to have a non-simplified version of an expression. A perfect example of a place where this simplification would not be helpful is if you had a complex expression and were trying to identify commutators in it `[sx,sy]`. This becomes impossible in automatic simplification is done. Another place I use unsimplified expressions is when teaching. Then, I really want to show that `[sx,sy]=sx*sy-sy*sx`.
* But ultimately, the golden sympy rule is this "don't do simplification automatically unless all users will want it all the time". I don't think this case comes close to this test.