Health API: Decouple result fix from severity

[infeo]

Currently, the (undocumented) convention for an implementaiton of DiagnosticResult is the following: result severity != WARN → do not override fix() method. (aka throws UnsupportedOperationException).

In the context of https://github.com/cryptomator/cryptofs/issues/128, this convention showed a lack of flexibility. The dirId backup file is an optional feature, but the result stating it's missing has a severity of WARN to be fixable. Additionally, a lib consumer is unable to reach an intact vault structure once a critical error appears. This leads to reserved file paths, undeletable resources and other permament errors.

This PR solves those problems by discarding the aforementioned convention. The ideas are

• give the consumer the information she needs to make decisions
• provide tools to fix the vault structure and make the filesystem error free again
• only consider the current local state of the vault

The ideas are realized by decoupling the severity and the fix() method of a DiagnosticResult and change their meaning:

• The severity serves as an indicator if the vault structure is compromised or data loss happened. It does not make statements about if the result can be fixed/resolved.
• The fix method exists to heal the vault structure. More technically speaking, it resolves the result by altering files and directories, such that the result is not triggered anymore by a subsequent run of the same health check.

Implementationwise, the javadoc of Severity is adjusted. The feature to determine if a result fix exists is moved from convention to implementation: DiagnosticResul::getFix is a new method which returns Optional<Fix>, where the latter class is just a functional interface to apply the fix. The default implementation of ::getFix returns an empty optional. To keep compatibility, method fix(...) still exists, but is deprecated. For existing results with fixes, a delegate method is implemented.

[infeo]

Remark: To keep the diff small, this branch merges into https://github.com/cryptomator/cryptofs/tree/feature/missing-c9rcontent-is-type. There is an open PR for that one: https://github.com/cryptomator/cryptofs/pull/148

Once merged, the merge target should be changed to develop.