Reduce the number of `Storage` kinds and simplify `StorageFactory`

[armiol]

At the moment there are several types of Storages produced by StorageFactory and their number is growing with the introduction of CatchUpStorage and InboxStorage.

Any SPI user has to put much effort into dealing with similar problems when providing their custom StorageFactory implementation. While in fact most of them can be basically simplified down to three operations:

• Write the Message representing either a state of an Entity or just a message, such as InboxMessage.
• Read a single Message or several Message instances according to the fields stored alongside with the Message payload BLOB.
• Modify the lifecycle flags associated with the Message. Most likely, they are deleted and archived flags of an Entity.

So a proposal is to perform the following steps.

1. Have a single Storage kind, capable of storing Message BLOBs along with some distinct fields.
2. Re-use the language we already have in Query as the definition for field fields, ordering, sorting and limit. Allow the Storage to use this part of Query language for reading the Messages from the storage.
3. Re-implement all the custom lookups we have at the moment in different typed Storages as a combination of Query language predicates built on the Repository level.

In this way, the SPI users will have to provide just a single implementation of the Storage for their custom infrastructure — or to choose among the Spine-provided storage implementations.

[armiol]

@alexander-yevsyukov @dmdashenkov FYI.

[alexander-yevsyukov]

This issue is being addressed in the PR #1259.