This commit is still very VIP

- Clients can register implementations of the metadata handler using
  @exif.register(exif.Methods.XXX)
- For copy_metadata, get_raw_metadata, get_formatted_metadata, and
  get_keys all registered implementations are run, and the output
  combined, for get_date_time, only the last registered one is used
- Two internal plugins for metadata support, using piexif and py3exiv2
  respectively, were added

Module functions indicate whether any implementations for the
Methods have been registered, and hence, what functionality
MetadataHandler is able to provide.

- MetadataHandler no longer has two operations that distinguish between
formatted and raw metadata. Such a functionality can be added later if
needed.
- exif.Methods was renamed to exif.Operations
- Docstrings were added
- Minor fixes

Consecutive calls using the same arguments are cached and served from
cache. This applies for the backend setup, get_metadata and get_keys, as
these are rather expensive calls.

This may be problematic if metadata is written to the image in-between
calls.

Renaming is done as this file handles all metadata related
functionalities and not just exif metadata.

Clients no longer register individual functions, but they subclass
`MetadataPlugin`, and overwrite whatever methods the plugin offers.
In addition, clients are required to set the `name` and `version`
field of `MetadataPlugin`.
The subclass is registered using the register function.

Also rename plugin from py3exiv2 to pyexiv2 to prevent confusion.

Changing MetadataPlugin to a abstract class:
- Enforces the client to set both, `get_metadata` and `get_keys`
    - `copy_metadata` and `get_date_time` is optional to implement
- Enforces the client to set `name` and `version`
    - Both are now a property. Prevents the loading of plugins if not
      used.

Additional changes:
- Simplified `_registry` to be a simple list. There is no need for a
  dict. Also, the additional `_has_...` properties are no longer needed.
- Got rid of all module level `has_...` functions, and added
  `has_metadata_support` instead. Fine-grain control is not needed.

This is a first attempt on fixing the tests for the redesign of the
metadata handling:

- The metadata_markers (old exif_markers) have been adapted. However, I
  do not think that they make sense. For `metadata` and `nometadata` the
  condition only indicates whether the current instance of vimiv has
  metadata support (or not). For `piexif` and `pyexiv2`they indicate if
  the backend package is installed.

- In addition, having condition `metadata_pyexiv2.pyexiv2 is not None`
  fails for mark `pyexiv2`. I am not sure why that is the case.

- Fixtures `metadata_support`, `no_metadata_support`, `piexif` and
  `pyexiv2` have been added and implemented. They bring
  `metadata._registry` into the respective state, and make use of
  `reset_metadata_registration`, to undo the changes after each tests.

- Updated `test_version`. Am I required to set for each testcase the
  mark, as well as appropriated fixture (i.e. `@mark.piexif` and specify
  `test_XXX(piexif)`. This seems a bit tedious.

While they are absolutely required to run the plugin - and I thus
thought they could stay required - running the test suite without piexif
/ pyexiv2 is very messy with them not being optional. We need to be able
to compare to None there.

As we now rely on a plugin infrastructure, the old unit test no longer
makes sense. Thus the test is now moved to integration and can be
expanded in the next steps.

With the new plugin structure, adding this information directly to
--version is no longer simple and up for discussion.

The signal is emitted when plugins have been loaded. This allows the
mainwindow to initialize the metadatawidget afterwards, and only if
metadata related plugins have been loaded.

As these are now plugins, they are not available this early in the
loading process. Instead plugin information should be added in :version
explicitly.

Unfortunately using metadata.has_metadata_support() does not work this
early in the code, as we import conftest much before loading plugins and
actually registering the metadata handlers.

Avoid importing the widget without metadata support as this registers
the :metadata command.

The metadata is stored in self._metadata, while metadata is the actual
module.

This allows loading metadata support by default, as is the current
behaviour. We can consider deprecating this over time, but we should
definitely keep metadata support by default as it is currently the case
for now.

- Simple tests to check if piexif / pyexiv2 correctly register the
  metadata handler
- Correct skipping of fixtures with pytest.mark.piexif /
  pytest.mark.pyexiv2

While a property is well suited to get this data, having to call these
properties on an instance of MetadataPlugin does not really make sense.
While it is possible to implement classproperties, `abc` cannot enforce
their implementation out-of-the-box.
Therefore, the properties were changed to static methods.

`get_metadata/get_keys` do not raise NotImplementedError. This is a
leftover from before refactoring MetadataPlugin into an abstract class

Changed the `UnsupportedMetadataOperation` exception to a more general
`MetadataError`. It gets called when a `MetadataHandler` method is called
without any metadata plugin registered, or if none of the registered one
provides support for `get_date_time`/`copy_metadata`.

Remove backward compatibility: Someone having the old piexif keys
defined in their config, but wanting to use the pyexiv2 backend.
Maintaining this backward compatibility required ugly guessing of
potential key prefixes.

Assertion in `add_exif_inforamtion_bdd` is not reached when piexif is
not available. The fixture `exif_content` fails before with an
AttributeError NoneType.

Make sure that the extracted metadata is displayed in the same order, as
specified in the config.

The dict returned by `get_metadata` was keyed by the *truncated*
metadata key, and not the original one. As the metadata widget uses the
original keys to read out the data, nothing was displayed if long keys
are used in the config.

I did not replace the link with one to `metadata.rst` as this lead to
a weird error. I also do not think that this link is super relevant.

If no metadata plugin has been specified, the default `metadata` plugins
loads one of `metadata_pyexiv` or `metadata_piexif` (depending on the
installed backend). If a specific backend is configured, they it is
ensured that `metadata` does not interfere.

This is achieved by deferring the loading of the `metadata` plugin to
the end of all plugins. At that point `metadata` can check if another
metadata plugin has been loaded, and if so, do nothing.

User plugins are now loaded before app plugins, and not overridden. This
allows metadata (and any other app plugins) to be loaded later and
access any user-specific information. In this case, the user can
deactivate auto-loading by passing

metadata = none

in the plugins section of the config.

Also make them Title Case, as in other pasts of the docs