Improving astropy.modeling.fitting by returning parameter errors and final statistics value

### Description
At the moment the fitters implemented in `astropy.modeling.fitting` fundamentally return a `FittableModel` with its parameters set to the values that make the fit converge.
Any other information of interest for the statistical analysis is cluttered in the `fit_info` object which is **not uniform** among the different type of fitters.
For example `LinearLSQFitter` and `LevMarLSQFitter` have different keywords in their `fit_info` dictionaries ([`fit_info` for `LinearLSQFitter`](https://github.com/astropy/astropy/blob/master/astropy/modeling/fitting.py#L279), [`fit_info` for `LevMarLSQFitter`](https://github.com/astropy/astropy/blob/master/astropy/modeling/fitting.py#L804)). Other classes instead return for `fit_info` something completely different ([an example here](https://github.com/astropy/astropy/blob/master/astropy/modeling/fitting.py#L1035)).

I think the fundamental informations I'd like to fetch after fitting are
- the **errors on the parameters**, these at the moment have to be extracted manually by the user from the different `fit_info`;
- the **value of the statistics** when the model converged. This might be useful for example for a chi square comparison, likelihood ratio test, or if we want to profile over nuisance parameters.

### Proposal
For the **parameters errors**
- one could modify the `Parameter` class itself to add an `error` attribute which is filled by the `Fitter`;
- one can create another object in the `Fitter` which contains both parameter and error, for example a `FittedParameter`;

for the **final statistics** this can either be an attribute of the `Fitter` itself or a standardised keyword in the `fit_info` dictionary.

What do you think?

Thanks

Start by reading astropy/modeling/fitting.py, especially the fit_info handling for LinearLSQFitter, LevMarLSQFitter, and the other fitter example linked in the issue. Compare how parameter errors and final statistics are currently exposed, then define a uniform public API and its completion criteria before implementing it. Add or update fitting tests to cover the supported fitters and verify consistent results.

Written by the indexing model from the issue text.