Model refactoring stage 2

This is the followup to #2580, though it also builds upon (the as of yet unmerged) implementation for #1763.

The major changes here, thus far, are:

1) Rather than having an `n_inputs` and `n_outputs` integer attributes, model classes now have class attributes called just `inputs` and `outputs`, each of which is a tuple giving unique *names* to each input coordinate and output that a model has.  `n_inputs` and `n_outputs` are still support, but simply return the lengths of these tuples.

One thing that might still take some thinking is some sensible names for the inputs out and outputs of each model, but so far several defaults are used that are consistent with the existing implementations.

2) For subclasses of `Model`, the function signature for its `__call__` method automatically reflects the names of the model's `inputs` (unless `__call__` has been manually defined by the model's author, though there's usually no reason to do this since the changes in #2580).

3) Likewise, the signature for each model's `__init__` method automatically reflects the model's parameter names, unless the class's author has manually provided an `__init__` method.  This is a little more common (see the polynomial models) than overriding `__call__`.  But for most models this still allows cutting out a lot of boilerplate.


If this seems like it's starting to go overboard with the metaprogramming, keep in mind that a lot of this work is in support of defining compound models.  Some of this is still a bit experimental though and could use some feedback (I have already tested gammapy and photutils successfully against this PR).
It shouldn't.  The new composite model implementation is (supposed to be) my top priority right now.  It will definitely be incorporated sometime well before 1.0 (possibly even in a couple weeks).