[Meta] Implement OpenAPI 3.0 spec

@e0ipso, I definitely think this is a major consideration.

It's been a while since I last visited the 3.0 spec version. Are I know there a a number of items which improve the API definitions. Are there specific ones which you would want to focus on or that would benefit us (devour-drupal) the most in the short term?

Ultimately I think we need to put together a list of the changes and start working through them. Are you at all familiar with what's changed? If not, I can try to put together a list later this week so we can start to see how much work it is, and how serious the update is.

I would be weary of moving to 3.0 spec on the 8.x-1.x version of the module, which might cause confusion. Likely I would recommend moving to a new 8.x-3.x release, which could include the new features. Likely then depricating the 1.x branch. I still would like to make that branch as feature complete as possible in the short term (include mostly up to date specs with correct meta data). Then only focus on 3.0 after that.

This is also a great opertunity to move to overhaul schemata, implement jsonapi_schema, or whatever we create as the generic hybrid version.

If you have the knowledge to put together a openapi spec changes list (or find and link one) I can see what needs to be done on the module side.

Another major benefit of 3.0 spec, is links.

This would allow us to implement basic hypermedia support, which validation, which would be awesome.

I see two major questions around links

1. What are the default links? - I think the basic crud operations can be defined easily, but there may be other actions which aren't, like linking two entities or similar functions.
2. How do apis (think commerce cart api) define links? - I'm thinking about things like the cart api, and how it could attach an "add product to cart operation" to the jsonapi doc.

I think to make this work nicely, we would need to implement an extended plugin system, where things like links can be added by modules. I'm however not sure the best way to map this data. It may make sense to convert the operations (route+method) into plugins (with derives) so that link plugins could wrap route plugins. This requires a bit of work, but is totally doable. I think I would also move to convert the schema/definition system to use plugins as well, which would clean up the code a bit, and allow for more re-usability between rest and jsonapi.