Feat: New TfComponents package to export RoleMap, Capability and TimeLock from product_core

[chrisgitiota]

Description of change

This PR introduces the new Move package TfComponents in product-core. The package is contained in folder "components_move". There will probably also be Rust and TS bindings for these Move modules (see below).

As a first step to move the following modules from the Notarization repo to product-core, the modules have been copied into TfComponents and module paths and docs have been migrated accordingly:

• audit_trail::role_map
• audit_trail::capability
• notarization::timelock

The Move type TimeLock offers new additionally variants UnlockAtMs and Infinite.

Rust and WASM bindings for TimeLock and new TimeLock variants

The Rust and WASM bindings for TimeLock are still located in the notarization repository. The plan is to move these bindings into new product-core packages:

• A Rust package tf_components contained in folder components_rust
• A Rust and TS package components_wasm contained in folder bindings/components_wasm

This will be implemented in a future PR.

How the change has been tested

• Move tests in components_move can be run as usual: iota move test
• The Audit Trail RoleMap & Capabilityintegration and the Notarization integration for TimeLock has been migrated to use TfComponents in the feat/audit-trails-dev-product-core-role-map branch. All former existing tests can be run successfully.

[itsyaasir]

One Small thought: some doc comments repeat what the code already tells us:

/// `* ctx`: The transaction context
/// - `role_map`: Reference to the `RoleMap` mapping.

Similarly, in these comments

  /// - role_map: Reference to the `RoleMap` mapping.
  /// - cap: Reference to the capability to be validated.

The function signatures make this clear, and thanks to the field naming you chose, I feel it is self documenting and doesn't require the comments.

Comments are a maintenance liability — when code changes, comments must too, or they become misleading. Verbose comments that duplicate the code tend to drift out of sync over time.

What's valuable to keep:

• Error conditions / abort scenarios
• Non-obvious behavior (e.g., valid_from is inclusive, valid_until is
  exclusive)

Consider trimming:

• Parameter descriptions that mirror the type signature

/// Creates a capability with no address or time restrictions.
///
/// Aborts with `ERoleDoesNotExist` if role is not in the RoleMap.
public fun new_capability(...)

Just a suggestion, I am happy to discuss!

[chrisgitiota]

IMO we should discuss the "doc comments" outside of this PR. Already sent some thoughts on this @itsyaasir.

I couldn't resolve the comment BTW.