Currently, we create a database read view only to create a memtx
snapshot or join a replica, but there's already quite a bit of code
duplication between these two scenarios. In the future, we will need
the same functionality to create a user read view. So let's factor out
this code into a separate module - read_view.

The API of the read_view module is quite simple - there are just two
methods: open and close a read view. The user can pass a space and index
filter while opening a read view to skip certain spaces. E.g. we skip
all temporary spaces and secondary indexes when we create a memtx
snapshot. A read_view object has a list of space_read_view objects, one
per each space included into the read view. A space_read_view object, in
turn, has a map of all index_read_view objects (introduced earlier)
corresponding to space indexes. There's nothing like a space cache - the
user can create one if required.

An engine that supports creation of a read view (currently, only memtx)
is supposed to set the ENGINE_SUPPORTS_READ_VIEW flag and implement the
create_read_view engine method in addition to the create_read_view index
method. The engine method should do some engine-wide read view related
preparations. For example, in case of memtx, it suspends tuple garbage
collection.

Closes #7363

NO_DOC=refactoring
NO_TEST=refactoring
NO_CHANGELOG=refactoring