Store: count block store status changes

This MR aims to change the store's status encoding from Merging|Idle to Merging int | Idle int.

The integer aims to track changes that may have occurred between two looks to the status, and thus, notice if multiple changes occurred.

This is necessary for !9490 (merged).

Context

The MR is structured as follows:

1. Move bits of existing code between files for better organisation (will help the following commits)
2. Refactor the block_store_status type into a module
3. Moving the old block_store_status to a Legacy module inside the one created at the previous commit
4. Adding the new block_store_status version with a version upgrade (v.3.0 -> v.3.1)

Manually testing the MR

Starting from current master with storage version 3.0 and legacy status file:

$ ./octez-node run --data-dir ~/.tezos-node-ghostnet --rpc-addr localhost:8733 --net-addr localhost:9733
...

$ cat ~/.tezos-node-ghostnet/version.json
{ "version": "3.0" }

$ xxd status
00000000: 00

Then checkout to this branch:

$ git checkout vicall@store_merge_status

$ make

Now, after stopping the node and re-running it, we get an automatic upgrade from 3.0 to 3.1 and the node runs normally:

$ ./octez-node run --data-dir ~/.tezos-node-ghostnet --rpc-addr localhost:8733 --net-addr localhost:9733
Apr 24 12:46:02.754: upgrading data directory from 3.0 to 3.1
Apr 24 12:46:02.755: the node data dir is now up-to-date
Apr 24 12:46:02.755: the node's data directory was automatically upgraded from 3.0 to 3.1 and is
Apr 24 12:46:02.755:   now up-to-date
Apr 24 12:46:02.783: the node configuration has been successfully validated.
...

$ cat ~/.tezos-node-ghostnet/version.json
{ "version": "3.1" }

$ xxd status
00000000: 0000 0000 00  

Finally, going back to master:

$ git checkout master

$ make

$ ./octez-node run --data-dir ~/.tezos-node-ghostnet --rpc-addr localhost:8733 --net-addr localhost:9733
octez-node: Error:
              Invalid data directory version '3.1' (expected '3.0').
              Your data directory is too recent for this node version.

Which is a clear indicator that the user should not switch back to an older version.

Checklist

• Document the interface of any function added or modified (see the coding guidelines)
• Document any change to the user interface, including configuration parameters (see node configuration)
• Provide automatic testing (see the testing guide).
• For new features and bug fixes, add an item in the appropriate changelog (docs/protocols/alpha.rst for the protocol and the environment, CHANGES.rst at the root of the repository for everything else).
• Select suitable reviewers using the Reviewers field below.
• Select as Assignee the next person who should take action on that MR