Restructure `Parameters` to interface directly with `Pybamm.ParameterValues`

[BradyPlanden]

Feature description

At the moment, we construct a Parameters class that acts as a container for the Parameter class with added functionality. This has been helpful for multiple reasons, including acting on all parameters at once, piping the parameters to different formats (as_dict()), and co-locating all optimisation parameters together for plotting, results, etc.

This being said, this Parameters class adds confusing and lacks clarity on it's difference to the pybamm.ParameterValues class for users and developers. To better integrate pybop's Parameter class with pybamm and remove this confusion, I'm proposing pybop parameters become contained within the pybamm ParameterValue class itself. This would require duck-typing the Parameter class to ensure seamless integration, but this could look like the following:

# Builder
builder = pybop.builders.Pybamm()
builder.set_dataset(dataset)
builder.set_simulation(model, parameter_values=pybamm.ParameterValues("Chen2020"))
builder.add_parameter(
    pybop.Parameter(
        "Negative electrode active material volume fraction",
        initial_value=0.6,
        prior=pybop.Gaussian(0.6, 1e-2),
    )
)
builder.add_cost(pybop.costs.SumSquaredError())
problem = builder.build()

# Interacting with ParameterValues
params = problem.parameter_values
type(params)  # pybamm.ParameterValues
type(params["Negative electrode active material volume fraction"])  # pybop.Parameter
print(params["Negative electrode active material volume fraction"])  # 0.6

# Inheriting from numbers.Number
neg_volume_fraction = params["Negative electrode active material volume fraction"]
neg_porosity = 1.0 - neg_volume_fraction  # 0.4

# Adding numpy support
neg_porosity_array = np.asarray([1.0 - neg_porosity, neg_porosity])  # [0.4, 0.6]
volume_fraction_available = np.isnan(neg_volume_fraction)  # False

# Using our current methods
sample_neg_vf = neg_volume_fraction.rvs()  # 0.59483
vf_prior = neg_volume_fraction.prior

This restructure would require much of the Parameters class logic to be ported into the Problem class, which could have larger issues across the codebase, but I think a few of these methods, such as get_bounds, update, rvs are probably better located within that class.

One major advantage of this is that once inference or optimisation is complete, the final pybamm.ParameterValues instance is immediately executable by pybamm models, and can include uncertainty information from the optimisation/sampling process.