Enhancements to Quantity tutorial

Thanks for all the work on this, @abonaca!  I've made a variety of minor formatting changes here, and a few items that are a bit more substantial:

* I changed the definition of an H2 unit's mass to use  amu/Daltons in the CO example.  I think that better showcases that there's no need to worry about knowing the value of various things in solar masses - just put it in the most natural units (in this case, amus are what most molecular weights are in), and let `astropy` take care of the rest.
* I made some adjustments to the discussion of sterradians and the `dimensionless_angles` equivalency in a way that I think is a bit safer of a way to use it.  Take a look and let me know if that makes sense, or if you'd rather change it back to the way it was.
* I changed how the CO data cube is created to use a more numpy-like approach, and similarly adjusted where the `dv` and such are defined.  This is significantly faster because there's no for loop, but at the price of being a bit more opaque.  Let me know if you think it's better to stick with a for loop (as long as there's a warning that this is an inefficient way to do it for real science code).  Note that this ended up changing the pixel scale... I'm a bit confused by the original version, because the pixel sizes and array dimensions didn't seem to be consistent.  This might be a cos(dec) thing, which I've avoided here by changing the dec to be very close to 0.
* I also added a bit more scientific background about the stellar mass example and added a bit more where the actual mass estimator is used.  Let me know if you think it's hard to understand or anything.
* I also added the section 3 I've been promising.  It's a bit short, but I think it gets the point across.  I welcome any comments/suggestions, though.


Now some somewhat more general "stylistic" comments - mostly just tips for things you might want to know about in the future, none of them require action as I've corrected them where relevant:

* In the future, you might also want to do "Cell-> All output-> Clear" in the notebook interface before doing git commits.  That clears all the input/output from the actual saved notebook, which makes it easier to see what changes have been made when looking at git diffs.  It also removes all of the rendered images, so a lot less space is taken up by the notebook file.  Not crucial, but it makes it easier to follow what's going on in the git repository.
* There are a few places where you reference variable names in markdown text, but you just do it as raw text (e.g., ``It is conventional to load astropy units as u.``).  In markdown you can use backticks (e.g.,``It is conventional to load astropy units as `u`.``) to indicate something is an actual variable name - it will render with a different font on different systems, but the key is that it's different from the regular text.  You can also use double-backticks to actually show code examples (although in the notebook you may as well just use a code cell).  Note that the same scheme also applies for github comments (which are in markdown). I've gone through and added them where relevant, but I thought I'd just mention that for future use.  
* Along similar lines, when talking about something like a "quantity object", it is helpful to make it clear which part is actually the *name* of the object.  For example, instead of saying  ``quantity object``, you might say `` `Quantity` object`` - the part in backticks is the actual name of the class, as it would be used or seen in code (including capitalization).    
* Along with the convention of putting spaces after commas, another code convention we use is putting spaces around ``=`` when assigning variables.  More generally, spaces should be around *all* operators, although sometimes that guideline is ignored for mathematical expressions where it makes things more confusing (or for `Quantity`, where e.g., ``29*u.pc`` is easier to make sense of in a long expression than ``29 * u.pc``). This is all motivated by [PEP8](http://legacy.python.org/dev/peps/pep-0008/), which describes a variety of guidelines for making code easier to read.  Actually following all that religiously makes you a very pedantic person, but for presenting to a large audience like these tutorials, it helps make the code easier to understand. (I see later on your are doing this, so maybe you know already, but I thought I'd make sure.)


Once this is merged, @jfoster17 can take a look, particularly at section 2, and he may want to make some tweaks in his own PR.