Saving Model Parameters to File

### Description

I don't believe there is a way to write out models to file. It would be useful to have the machinery to write out model parameters as FITS tables, ECSV, or YAML files. I think this feature should mainly focus on saving the parameter values as opposed to the model itself (for example it should not pickle the model object). As of opening this issue, the feature should be able to:

1. Save model parameters to file.
2. Have unit support.
3. Metadata of the model class that the parameters come from. If the model is a compound model, it should also have data on the individual models that created that compound model. This metadata is only for documenting the parent model and not to be used for recreating the model. It should be on the user to choose the appropriate model based on the metadata they see in the file. In the future, we could introduce machinery to recreate models (in the future because custom models can be tricky to pull off).
4. Either have `load` function for all model classes (probably in the base classes), where a copy of the model itself is returned with the loaded parameters --or--- a single function to load and convert parameters into quantities that can be used to initiate the model, for example:
```
>>> model.write_params(file_path)
>>> new_model = SomeModel2D.read_params((file_path)
```

```
>>> kwargs = load_model_params(file_path) # returns dict of quantities
>>> new_model = SomeModel2D(**kwargs)
```
5. Since this has us thinking about how to save parameters, we should also attempt or think about attempting to save bounds and fixed parameters.

My thinking is that it would be easy to do all of this using the astropy table machinery. We would add bounds and whether or not a parameter is fixed as separate columns in the table. This table can save the data to whatever format the user wants (though we should restrict it to formats that can store metadata). What I am not sure about is how the API should work, should this be a function in the model like `Table.read(file_name)` (i.e `SomeModel2D.read(file_name)`) or an external function like the code block above?

I would be willing to look into this if this idea seems interesting. All help, suggestions, and constructive criticism welcome!

### Additional context

Related to [PetroFit ticket](https://github.com/PetroFit/petrofit/issues/18)

No implementation files or tests are named. Start by reviewing the model classes and the Astropy Table machinery mentioned in the issue, then resolve whether the API is model-based or external. Done should cover parameter values, units, model metadata, and a documented approach for bounds and fixed parameters across supported file formats.

Written by the indexing model from the issue text.