Towards a more extensible `NLPModels.jl`

During development of [`CCOpt.jl`](https://github.com/MadNLP/CCOpt.jl) and [`MPCCModels.jl`](https://github.com/MadNLP/MPCCModels.jl) I have had the chance to develop some ideas about how to improve the `NLPModels` ecosystem. Namely there are a few major pieces of the current state which make it difficult to develop new model types and to exploit knowledge of the model type at the solver level. Three particular things are:

1. The forest of booleans which live in the `NLPModelsMeta` defining what parts of the `NLPModels` API a given model supports.
2. The linear/nonlinear API.
3. The difficulty of writing wrapper types which can expose to the solver their characteristics in a multiple-dispatch friendly way.

To improve 1,3, I propose to move as much of the forest of booleans to type parameters of the `AbstractNLPModel` type.
This would allow much cleaner specialization of solvers to particular model types (particularly things like `QuadraticModel` or `LinearModel` where we could implement avoiding function reevaluation easier). It also would allow better specialization for solvers in cases where some of the optional api methods are implemented. In principle this is all possible now but requires messy `if-else` cases throughout solver code.

For point 2 I think the suggestion made in #511 makes a lot of sense. Paying a quadratic-in-nonzeros price or having to re-implement everywhere the api for the linear/nonlinear split is quite painful, and not always possible (e.g. in some cases a downstream model which you wrap may call the default slow implementation anyway, because someone didn't implement things correctly).

Additionally I would propose standardizing on the fact that `meta.*` fields should not be directly accessed. Direct access means that (as is done in some places) wrapper meta's are forced to implement the _whole_ list of fields rather than be more cleanly implemented as composition of `AbstractNLPMeta` structs (as is done in `MPCCModels.jl` and `CCOpt,jl`). This will make migration less painful when fields of `NLPModelMeta` change.

I will slowly start implementing these ideas in a PR, so they should become more clear as that implementation takes shape, but I am happy to discuss.

Start by reviewing the current AbstractNLPModel and NLPModelMeta design, the linear/nonlinear API, and the proposal in #511. The issue is exploratory; done would require a concrete implementation and discussion of type-parameterized capabilities, wrapper composition, and non-direct meta access.

Written by the indexing model from the issue text.