
TODO: TODO_08_25_32_95: redesign `class_to_collection_map`

It makes little sense, it should make more.

It was created for the single "technical" purpose - to FS_56_43_05_79 search diff collection.
Yes, it served its initial purpose, but:

*   It is not needed in most of the cases.

    Not needed because combination of these 2 factors eliminates the need to specify it:

    *   Most of the time, each `envelope_class` has to be loaded into its own `collection_name`.

        The only reason to combine multiple classes is the possibility to search them together.
        But then, their search props has to be similar in that case.
        That makes them belong to the same class (by duck typing), isn't it?

    *   Loading multiple `envelope_class`-es into single `collection_name` combines their sets of `index_prop`-s.

        If `index_prop`-s are drastically different, why are they in the same search collection?
        Searing them together is unlikely.

    In short, we can always rely on default mapping where `collection_name` = `envelope_class`.

*   On the other hand, `class_to_collection_map` is the only way to know what collection to search for given class name.

    But that is already set in `search_control` - once it is put there via `class_to_collection_map`,
    it is never used again from `class_to_collection_map`.

    In fact, server-internal `class_to_collection_map` is only used by loaders and delegators to sync:
    *   Loaders load classes into correct collections.
    *   Delegators set up `search_control` so that funcs search correct collections.

    This can be left as convention (and flexibility to break it between loaders and delegators).

