Enforcement of synchronous replication for system spaces

Product: Tarantool
Since: 3.2
Root documents: https://tarantool.io/compat/box_consider_system_spaces_synchronous
and https://www.tarantool.io/ru/doc/latest/reference/reference_lua/box_space/
and https://www.tarantool.io/en/doc/latest/concepts/replication/repl_sync/
and https://www.tarantool.io/ru/doc/latest/reference/reference_lua/box_info/synchro/
and https://www.tarantool.io/en/doc/latest/reference/reference_lua/box_schema/space_create/#space-opts-is-sync

Synchronous replication is now enabled for most systems spaces when the
synchronous queue is claimed (i.e., box.info.synchro.queue.owner ~= 0),
regardless of the user-provided is_sync space option. We do not enable
synchronous replication for the following system spaces:

• vinyl_defer_delete - it's a local space, doesn't need replication;
• sequence_data - it's synchronized by synchronous user spaces
  operations.

A box_consider_system_spaces_synchronous backward compatibility option
was added to control this behaviour - please add a new
https://tarantool.io/compat/box_consider_system_spaces_synchronous page for
it.

A new read-only state subtable for the Lua space object returned from the
box.space registry with an is_sync field is added to reflect the
effective state of replication for system spaces. For user spaces, this
field will always mirror the is_sync option set for the space.
Requested by @CuriousGeorgiy in https://github.com/tarantool/tarantool/commit/371fa0dc0f49a00bcc839b6a1976884a5d12fd80.

Create the compatibility page for box_consider_system_spaces_synchronous, using the linked compatibility and replication references as the starting point. Document when synchronous replication is enforced, the exceptions for vinyl_defer_delete and sequence_data, and how the read-only box.space state.is_sync field reflects effective behavior.