Show box configuration stages

[Totktonada]

box configuration has several phases. A user can access box in some of intermediate stages. Here I propose to bring more transparency about box's state.

The rough list of the stages (collected from the source code):

1. Normalize and validate options.
2. Restore box.<...> members (except execute). Stop raising Please call box.cfg{} first errors on accessing the members.
3. Apply non-dynamic and some dynamic options, initialize subsystems.
4. Load the database (local or remote recovery). !! This process yields periodically. !!
5. At this point box_is_configured() from box.cc starts to return true.
6. Initialize RAFT subsystem.
7. Apply remaining dynamic options.
8. Upgrade the database schema if needed and possible.
9. Restore box.execute (see e8d5515).
10. Set box_is_configured from load_cfg.lua to true.
11. Start flightrec if available.

Several thoughts around:

• The stage 4 (recovery) likely could be splitted into more stages: whether all system spaces are available, whether secondary indexes in memtx are available. Remote recovery likely will have its own set of stages.
• It seems, we can't reuse box.info().status for this purpose due to backward compatibility concerns. I propose to add another field.
• The list of stages should be extensible. Maybe even hierarchical.
• It would be nice to make the stages comparable. However it would be nice, at the same time, to make them human readable. Raw idea: '001 description', '002 description' and so on. Or, maybe, make them tables like {num = <...>, name = <...>}.
• Consider adding triggers to call a callback at reaching end of particular stage (see also box.ctl.on_ctl_event #3159).

The discussion originates from #7407.

[filonenko-mikhail]

The only thing I worry irrelevant here but seems that flight have to be first.

[Totktonada]

#7938 lands to future 2.11. The documentation request: tarantool/doc#3242.