Split conformance classes into multiple api modules

[francbartoli]

Overview

This PR organizes the conformance classes into different modules, one for each supported OGC API and use a generic dataclass to define the instance of each conformance class. It uses a temporary namespace api_ to do not collide with the existing api.py module while we are discussing the transition.

Related issue / discussion

It's been designed with the same intent of #1405 so it can be compatible with that approach

Additional information

Dependency policy (RFC2)

• I have ensured that this PR meets RFC2 requirements

Updates to public demo

• I have ensured that breaking changes to the pygeoapi master demo server have been addressed
• https://github.com/geopython/demo.pygeoapi.io/blob/master/services/pygeoapi_master/local.config.yml

Contributions and licensing

(as per https://github.com/geopython/pygeoapi/blob/master/CONTRIBUTING.md#contributions-and-licensing)

• I'd like to contribute [feature X|bugfix Y|docs|something else] to pygeoapi. I confirm that my contributions to pygeoapi will be compatible with the pygeoapi license guidelines at the time of contribution
• I have already previously agreed to the pygeoapi Contributions and Licensing Guidelines

[doublebyte1]

@francbartoli +1 for simplifying api.py . Could you just address the conflicts in that file?

[totycro]

This change has been integrated in the PR #1405 , e.g. here:
https://github.com/geopython/pygeoapi/pull/1405/files#diff-e041da9abca704e95b286a60a59ff2e161301127ddf7555298b823fffd51796bR59

I think everyone agrees that this change makes sense. To get it to main with the the least amount of conflicts, it might make sense though to close this PR and use the version which is part of the large diff of #1405

[tomkralidis]

+1. This is implemented as part of the api.py refactor in #1405 that will be issued for review/approval shortly.

[francbartoli]

Thanks for the feedbacks @doublebyte1 @totycro @tomkralidis. I see the overlap with #1405, however I believe this has the intent to represent conformance classes in a more object oriented way rather than simply dicts. This could be useful to make them loaded and offered dynamically based on the actual configuration and the parts really implemented by the overall specs. Maybe it's better to open another PR after the merge of #1405

[tomkralidis]

@francbartoli thanks, +1/agree to build up conformance based on config after #1405