This adds overridable config variables for mapping storage backend names to
classes (by default drawn from declared entry points) and setting a default
backend for new files.

It also adds a pyfs storage backend entry point, and makes it the default.

Storage backends should be `django_files_rest.storage:FileStorage` subclasses,
and declared with a `django_files_rest.storage` entrypoint.

…gress

At the moment, the storage backend is responsible for computing checksums and
reporting the size of files based on the number of bytes read. However, these
are common concerns across all storage backends, and so this functionality can
be pulled the other side of the storage backend interface.

This class is therefore intended to wrap any file-like object, and to checksum
the file as it is read. It also counts bytes and calls the progress callback if
one is provided.

In a subsequent commit we'll integrate it with FileInstance, and remove the
functionality from the PyFS storage backend.

This new storage factory uses a `FileInstance.storage_backend` attribute to
determine which backend to use. It uses the
`FILES_REST_DEFAULT_STORAGE_BACKEND` config value when the file instance
doesn't already have a storage backend.

It can be extended to customize how the backend is chosen, and how it is
initialised.

The file path is chosen based on the `id` of the file instance, but this can be
customised too.

It's not set as the default storage factory to preserve backwards compatibility.

…nit classes

This property can now instantiate class-based storage factories, i.e. the new
factory in `invenio_files_rest.storage.factory`.

It's possible the deprecation should be in the pyfs storage factory itself.

These aren't Py3.6-compatible, so will probably need to be removed later, or
replaced with comment-based annotations.

This will mean we can later remove this functionality from the storage backend.

This is exposed as a class property on FileStorage and can be accessed as
`FileStorage.backend_name`. It returns the associated backend name in the
application config, which can then be used to find the class.

It no longer needs to do checksumming, and the filepath can be moved to the
superclass.

All together because this has been very exploratory.

There's always a better option than metaclasses.

In this case, a classmethod, which also simplifies getting the backend name on
instances (`type(instance).backend_name` → `instance.get_backend_name()`)