Move entry schemas to separate submodule

[ml-evs]

This PR is a shortcut version of #277 whilst retaining most of its features. The ENTRY_INFO_SCHEMA constant dict has been moved to a new submodule and new extension fields ("support" and "queryable") are now made available so they can also be used by the validator more cleanly in #503, and eventually in the server code in #504.

All that is missing to enable #277 is to wrap this in a class to provide a nicer interface for implementations to use their own models in ENTRY_INFO_SCHEMAS rather than the hardcoded StructureResource etc. I think this is a less important point than the other bits though.

[codecov]

Codecov Report

Merging #511 into master will increase coverage by 0.00%.
The diff coverage is 100.00%.

@@           Coverage Diff           @@
##           master     #511   +/-   ##
=======================================
  Coverage   91.59%   91.59%           
=======================================
  Files          61       62    +1     
  Lines        3118     3119    +1     
=======================================
+ Hits         2856     2857    +1     
  Misses        262      262           

Flag	Coverage Δ
#project	91.59% <100.00%> (+<0.01%)	⬆️
#validator	63.73% <100.00%> (+0.01%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ
optimade/server/routers/utils.py	97.72% <ø> (-0.29%)	⬇️
optimade/server/routers/info.py	96.15% <100.00%> (ø)
optimade/server/schemas.py	100.00% <100.00%> (ø)

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update c34f8a0...c3285d8. Read the comment docs.

[CasperWA]

Looks good to me, thanks @ml-evs

On another note, are you sure we don't need to take allOf, anyOf, etc. into account in the recursive function?

[ml-evs]

On another note, are you sure we don't need to take allOf, anyOf, etc. into account in the recursive function?

I'm sure for now... I think the problem we were having was also providing a schema for the links endpoint, which was running into the multiple allowed response types. We don't have that anywhere in our structure/reference models so this should be useful as is.