Reconsider ResourceMapper and Quantity design

[ml-evs]

Following on from discussions with @markus1978 and @CasperWA in #797, we should consider refactoring much of the functionality provided by the Quantity class into the base entry resource mapper.

We could also think about using some of the nomenclature we have from the mappers already?

Originally posted by @CasperWA in https://github.com/Materials-Consortia/optimade-python-tools/pull/797#r636050872

[ml-evs]

One important problem with the current mapper: it does not cache the values it scrapes from the schema, which will be re-resolved for every request. This is a drawback of the current class-level definitions. Options:

1. Create a metaclass and cache the attributes at that level - I tried this, but it does not play well with the docs
2. Switch to mapper instances over types - would be a bit of a pain as implementations/tests need to be updated

[ml-evs]

NB: this is the advantage of using the Quantity approach we have now, as the un-cached properties are only touched on FilterTransformer init and are then baked into the quantities themselves

[ml-evs]

Have pushed a metaclass mapper implementation to 51d54a0795b70a19af8cf65eceeaaa81a3fe3419, will see how it goes