The paradigm of the `WorkChain` requires a user in an implementation to
define the workflow logic through classmethods of the `WorkChain`
subclass. While this gives great flexibility and choice to the user,
there is a risk that a user inadvertently chooses a method name that
already exists on the `WorkChain` base class. Usually the `super` is not
called in this scenario and so the functionality is broken.

The typical example is where the user uses the `run` method as a step in
the outline of the `WorkChain`. The work chain will still run, however,
only that one step in the outline is called. Since the logic to continue
to the next step in the outline is defined in `WorkChain.run`, which is
overridden and now no longer called, the rest of the work chain is
skipped without any warning or error message, leaving the user
scratching their head as to what happened.

Here we protect this and other public methods on the `WorkChain` class
to prevent them from being overridden in subclasses. This is
accomplished by adding the `Protect` class as a metaclass. Since the
`WorkChain` already has the metaclass `plumpy.ProcessStateMachineMeta`,
which it inherits from its `Process` base class, and all metaclasses
need to share the same base, `Protect` also subclasses the
`ProcessStateMachineMeta` class.

The `Protect` class provides the `final` classmethod which can be used
to decorate a method in the `WorkChain` class that should be protected.
If a subclass implements it, as soon as the class is imported, a
`RuntimeError` is raised mentioning that the method cannot be
overridden.

The test `test_report_dbloghandler` had to be fixed because it actually
suffered from the very problem that is being fixed. It used the `run`
method to setup the test, but since the `check` was never being called,
the test always passed, even though the code `self._backend` in the
`check` is incorrect.