Persistent WAL GC state

Dev. issue: https://github.com/tarantool/tarantool/issues/10154

Product: Tarantool
Since: 3.3.0
Root document:

• https://www.tarantool.io/en/doc/latest/platform/storage/persistence/
• new page in https://www.tarantool.io/en/doc/latest/reference/reference_lua/box_space/

SME: @ drewdzzz

Details

Connected with #4479, #4670

Now all replicas has WAL GC consumers persisted in space _gc_consumers.
When the replica is deleted from space _cluster, its consumer is deleted
as well. It ensures that xlogs needed for replica won't be deleted after
restart of instance. Note that they still can be deleted when we have no
space for newer xlogs.

Space is read only on recovery, so inserting a new tuple to this space
won't have an effect until restart. If the space contains an invalid
tuple, it is skipped on recovery and an error is logged.

Please create a separate section for space _gc_consumers as we do for
other system spaces. We should write there:

Space _gc_consumers is only read when recovery is finished, then
Tarantool only writes system information there in asynchronous mode.
Hence, the space shouldn't be used for statistics since its data can
lag behind actual in-memory state. Secondly, since space is read on
recovery and isn't read later, any insert/replace/delete in this space
will have NO effect until the instance is restarted.
Requested by @drewdzzz in https://github.com/tarantool/tarantool/commit/ab3746ba38f7316823c6191c1e7da511e7c1e7eb.

Start with the persistence root document and the reference_lua/box_space documentation linked in the issue, then find how other system spaces are documented. Add a separate section for _gc_consumers covering recovery-time reads, asynchronous system writes, stale statistics, and restart-required mutations. Done means the new section clearly explains these behaviors alongside the other system spaces.