…ne minor issue in comparison operators on parameters.

…. In particular this can fix the output units to the units of one of the parameters (in the case of many of the current built-in models the output units simply come from the amplitude parameter, which makes sense--the rest of the model evaluates to a dimensionless quantity). This may seem mostly superfluous at the moment, because when you call the model's eval of course you'll just get outputs in the same units as the amplitude parameter. However, this will be more important once we actually implement converting the parameter values to a common base for fitting and the like. So this provides a nice way to specify (without too much magic) how the model should determine the units of its output. Will add a similar mechanism for inputs.

…ith how to handle inputs with unspecified units. Previously my approach was to require all inputs to have explicitly specified units if any parameters are using units. But for now let's be a little more flexible and see where that takes us.

…all inputs when evaluating the model. As this made output_unit_types mostly superfluous (no need to check the outputs if we can check that the inputs will produce the correct outputs), it was removed. input_units more or less has the same semantics that output_unit_types did before I removed it. I think this simplifies things a great deal. Also continued to improve support for arbitrary unit inputs/outputs.

…ultiple inputs or outputs. Previously multiple inputs (outputs) *required* the input/output_units to be a tuple with a rule for each input. I later realized it would be convenient to still allow a single rule, so that the same rule can be applied to *all* inputs. This is convenient, for example, to write a rule that all inputs have the equivalent units. Same for outputs.

…nate the explicit for loop at the beginning of _prepare_input_units, and eliminate the awkward (and broken) toggling of an internal instance attribute depending on whether or not some inputs had units when the model is called.

…city's sake--it also makes clearer that if a Parameter has a unit specified at all that unit is *fixed* for all time (up to equivalencies). Also make sure to always show the unit in reprs, even for unbound parameters, and to copy the unit when creating Parameter copies.

…for their parameters, and improved some of the overall logic surrounding handling of parameters with units. Still split on whether Parameter.value should return a *Quantity*, or whether Parameter should masquerade as a Quantity itself, such that .value returns the dimensionless value (while .unit returns the unit in either case). Likewise split on whether Parameter.default should return a Quantity or not. These details will be easy to update depending on feedback.

…3912/files#r33822647 , ensure that __array__ returns a Quantity for parameters with units, so that np.asanyarray() on a parameter returns a Quantity.

…ompatible with the parameter units.

…mpatible unit, and also make sure that equivalencies are properly taken into account when setting the Parameter unit.

…et__), and make sure that setting Parameter.value takes a unitless value not a quantity.

… a model with parameters that have equivalencies attached to them.

…quire information about input values, and include an example of fitting a spectrum in Jy to data in K and in erg/cm^2/s/micron.

…with optional units

…in modeling.