Starts the move toward Parameter not being a list subclass (this was problematic because lists by their nature have mutable size, while a model's parameter dimension is fixed).  This changed how setting parameter values is handled for ParametricModels.  Now ParametricModel.__init__ takes as kwargs the values for each parameter and the base class handles setting the values for those parameters.  This was the easiest way to handle this in such a way that we could allow the Parameter *descriptor* to validate each parameter via Parameter.__set__.
Fixed a couple issues with setting the parameters on polynomial models. Also renamed all the **pars __init__ arguments to **parameters as part of an attempt to move toward more naming consistency...
Actually use Parameter.__set__ in PolynomialBase.__setattr__.  A little hackish but it gets the job done without too much code reuse.
Rename the ._instance attribute of the Parameter and Parameters classes to _model, which I think is a little clearer.
A couple more instance->model renames
Add a metaclass that can automatically generate the param_names lists--this was part of my plan since the beginning
A couple more fixes to the Polynomial models.  getattr for nonexisting coefficients now returns an AttributeError as it should.  Changed _set_coeffs to _set_default_coeffs--it now just sets a default value for each coefficient, but still allows the ParametricModel constructor to actually set any user-supplied parameter values.
Rewrote the Parameters object to not be a list subclass--this was always a bit flakey because the parameters list being a fixed size it never should have been a list (though some sort of ndarray subclass might have been okay).  The code for this is a little complicated, especially when it comes to getting/setting values in the list.  There might be some ways to better simplify this, perhaps even going so far as to have the model store all its parameter values in a single array to begin with.  But in the meantime this does simplify other parts of the code a great deal.  For example the fitter code does not need to understand or worry about any of the internal details of the Parameters list.  It can just assign values to it and the underlying model will update accordingly.