Compound models initial work

I'm creating this PR so that we have something to look at regarding compound models.  There's still work to be done on this feature, but this is a good start which brings in the majority of the new functionality.  There is still some more work needed before this can be merged, specifically:

- [ ] Resolve question of division--right now models only support `__truediv__`, but do not support `__div__`.  Perhaps it should just support both and treat them equivalently.  Since models don't really support integer-only operations there's not much sense in supporting integer division separately.  So maybe to avoid ambiguity it would be better to just support `/` which on Python 2 (without `from __future__ import division`) means `__div__` and otherwise means `__truediv__`, and never support `//`.  I haven't made any decisions about this yet...
- [ ] Add documentation (working on that right now)
- [ ] Maybe bug fixes
- [ ] Timing comparison--this would be separate from this PR but I would still like to add benchmark tests for models to the Astropy benchmark suite sooner rather than later.  I started work on writing some benchmarks but had to postpone it for now.  Some manually testing though suggests a slight uptick in overhead, though within an order of magnitude.  Some of that will also be improved by other code improvements I have in the pipeline (improvements overall to modeling, especially with how parameters are handled, not pertaining specifically to compound models).

The bug fixes refer to some issues @nden brought to light.  They could be considered corner cases, but it's still important to try to fix them sooner rather than later, though they could in principle be fixed separately from this PR.

There are several other issues with this PR that are mostly issues in the code that I would like to address sooner rather than later, but they aren't issues that affect the functionality a great deal from users' perspectives (with one exception, which is incomplete handling of parameter constraints--constraints can be added to new compound model instances just fine, but I haven't worked out a system for inheriting constraints from the models that compose a compound model).  Most of these code issues can be dealt with later.  While I would definitely be interested in specific comments on the code and implementation, just keep in mind that there are many known areas for improvement (most of which I think are mentioned in `# TODO` comments, but perhaps not all).

TL;DR I'm not happy with the overall quality of this, though I am pretty happy overall with the user-facing functionality, and also more interested in comments on that.

This PR also addresses #1054--although it does not add support for fitting to the old `Serial/SummedCompositeModel` classes, those are superseded by the new compound model framework, and models created with that framework do support fitting.
Is there a reason to prefer this composition operator order `(f | g)(x) = g(f(x))`, e.g. easier or more efficient implementation?

When I tried this I first got my example wrong because I assumed the other order: `(f | g)(x) = f(g(x))`.
I find that syntax and the advice to read "|" as "after" as described [here] (http://en.wikipedia.org/wiki/Function_composition_(computer_science)#First-class_composition) more intuitive.