[Request]: Version history for the dynamic `Notarization` object

### Feature description

**Idea**

Record the latest X object-version-specifiers of a dynamic `Notarization` object (which is a Lamport timestamp as being described [here](https://docs.iota.org/developer/iota-101/objects/versioning#move-objects)) to allow retrieval with the full-nodes `iota_tryGetPastObject` API function.

Knowing the `Notarization` object-version-specifier, users can fetch older versions of a dynamic `Notarization` object from an IOTA full node as long as this node doesn't prune those older versions. Fetching older versions will not be guaranteed but often possible.

**Implementation**

Although object-version-specifiers are monotonically increasing numbers, incremented with each object change, the object-version-specifier that refers to a specific version of a Notarization state (after it has been updated using the `update_state()` function) can be considered as a pseudo random increasing number.

To retrieve a specific historical Notarization state, we need a mapping of the `state_version_count`-number (incremented at each successful `update_state()` function call) and the resulting object-version-specifier. This mapping will be called `version_history` in the following.

As the `update_state()` function - being a Move SC function - can not determine the resulting object-version-specifier itself, the `version_history` would need to be

- managed by the notarization Rust library
- stored in an offchain data sink (local/cloud database/json-file, ipfs, ...)

For each new version of a dynamic `Notarization` object the Rust libraries `update_state()` function would store the `state_version_count`-number mapped to the object-version-specifier in the offchain data sink:

| state_version_count | object-version-specifier |
|------------------------------ | ---------------------------------- |
|0 | ........ |
|1 | 151184440 |
|2 | 161403660 |
|3 | ......... |

The above used object-version-specifiers have been taken from [this Notarization object on testnet](https://explorer.rebased.iota.org/object/0x354744923ecae0957822be4941d02c4de6e29da7012aaba3eb3072547595f66f?network=testnet)

The Rust library would provide a function to retrieve the object-version-specifier by the `state_version_count`.

The rust library would also provide a function having the `state_version_count` as input argument and providing the corresponding Notarization object fetched from the IOTA node. The function internally would execute a node call like this:
```bash
curl --location --request POST 'https://api.testnet.iota.cafe' \
--header 'Content-Type: application/json' \
--header 'Cookie: _6a8b3=446aeefa3ecf23e8' \
--data-raw '{
"jsonrpc": "2.0",
"id": 1,
"method": "iota_tryGetPastObject",
"params": [
"0x354744923ecae0957822be4941d02c4de6e29da7012aaba3eb3072547595f66f",
151184440,
{
"showType": true,
"showOwner": true,
"showPreviousTransaction": true,
"showDisplay": false,
"showContent": true,
"showBcs": false,
"showStorageRebate": true
}
]
}'
```

### Motivation

Knowing the `Notarization` object-version-specifier, users can fetch older versions of a dynamic `Notarization` object from an IOTA full node as long as this node doesn't prune those older versions. Fetching older versions will not be guaranteed but often possible.

### Requirements

TBD

### Open questions

_No response_

### Are you planning to do it yourself in a pull request?

Yes