loaders, deserializers: implement symmetry between request and response

[ppanero]

Changes

• Remove the create_request_parser, it was basically a default parser with no fields to parse and no preprocessors... The call to it was basically returning {} and no value of it was used (obviously, since it does not provide anything)... In short: sort of useless...

Terminology

• Loader: A loader is now in charge of loading the request meaning, putting everything related to a request (argument parsing, data deserializing, etc.) into a representation that is understand by the application.
• Deserializer (NEW!): Following the same approach than for serializing, we create the deserializers.

Example

• Response = Loader
• Serializer = Deserializer

Open Questions

• The current distinction of when the loader expects a body and when it does not is a bit unclear. Some abstractions might be needed there. For example the item read (GET@ItemView) or the item removal (DELETE@ItemView). See data flag in the load_item_request. Example: We might want to send a body on a DELETE for tombstone pages, but someone else might not want to.

Closes https://github.com/inveniosoftware/flask-resources/issues/29 Opens https://github.com/inveniosoftware/invenio-resources/issues/9 Closes https://github.com/inveniosoftware/flask-resources/issues/32

[ppanero]

As discussed IRL with @lnielsen , to be able to wrap up this module today and actually start implementing on it (and in consequence modifying it from real-life usage experience). I'm merging this, but I opened an issue for each one of the discussion points. And passed the context to them.