[Request]: Having more flexible `update_lock`

### Feature description

In the current implementation of the dynamic Notarization we have an immutable `update_lock` configuration parameter, specifying the time until state updates are locked. Once this point in time has been passed, the Notarization state can be updated at any time without any timely constraints.

The existing update-lock behavior could be described as **One Time Update Lock**.

In the following, two additional update-lock behaviors - **Periodical Update Lock** and **Unsteady Update Lock** - are described to achieve a more flexible update-lock behavior.

**Periodical Update Lock**

This type of update-locking is useful for periodic use cases (i.e. daily official indicators, hourly Sensor values, ...).

The *Periodical Update Lock*:
- Is defined by an immutable u32 value, specified at creation time of the Notarization object
- Specifies a time period that starts after each Notarization state update and must have been expired, before the Notarization state can be updated again
- Is stored as an additional field together with other immutable meta data of the Notarization object and is displayed as such to Verifiers and others

**Unsteady Update Lock**

This type of update-locking is useful for even more dynamic use cases where the time span between Notarization update changes is not constant.

The *Unsteady Update Lock*:
- Is defined by an argument `state-is-locked-until: Option` of the `notarization::update_state()` function, specifying the unix time for the next earliest possible Notarization state update
- Is stored as an additional field in the Notarization object and is displayed as such to Verifiers and others

### Motivation

Provide update-lock behaviors for two additional use cases:
- *Periodical Update Lock*: Periodic use cases (i.e. daily official indicators, hourly Sensor values, ...)
- *Unsteady Update Lock*: Allows Provers to satisfy requirements where Verifiers expect notarized data to be immutable for a not constant time span

### Requirements

TBD

### Open questions

_No response_

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

Yes