Add WrappingAdd to LinkReference trait bounds

[konard]

Summary

LinkReference should include num_traits::WrappingAdd (and potentially other wrapping arithmetic traits) in its supertraits.

Motivation

After removing the LinkType trait from platform-data (linksplatform/data-rs#16), all bounds that were on LinkType need to come from LinkReference directly. The WrappingAdd trait is needed for wrapping unsigned arithmetic in Hybrid (used for internal/external link reference encoding).

Currently, platform-data must add num-traits as an explicit dependency and add + WrappingAdd bounds alongside every LinkReference bound. If LinkReference included WrappingAdd, downstream crates could use T: LinkReference without additional trait bounds.

Proposed change

Add WrappingAdd (from num-traits) to the LinkReference trait definition:

pub trait LinkReference:
    // ... existing bounds ...
    + WrappingAdd
{}

Since WrappingAdd is implemented for all unsigned primitive integer types (the same types LinkReference is implemented for), this is a compatible addition.

Context

• Replace funty dependency with platform-num (Numbers) for LinkType trait data-rs#16 — Replace funty with platform-num
• feat!: replace funty with platform-num, remove LinkType data-rs#17 — PR implementing the change

[konard]

I don't like the name of WrappingAdd, instead we should use something like AdditionCapable, check something similar already exists in num traites and we really need, and check what the best practice naming for that.

We also support similar for other operations that are usually supported by numeric types.

We need to download all logs and data related about the issue to this repository, make sure we compile that data to ./docs/case-studies/issue-{id} folder, and use it to do deep case study analysis (also make sure to search online for additional facts and data), in which we will reconstruct timeline/sequence of events, list of each and all requirements from the issue, find root causes of the each problem, and propose possible solutions and solution plans for each requirement (we should also check known existing components/libraries, that solve similar problem or can help in solutions).

If there is not enough data to find actual root cause, add debug output and verbose mode if not present, that will allow us to find root cause on next iteration.

If issue related to any other repository/project, where we can report issues on GitHub, please do so. Each issue must contain reproducible examples, workarounds and suggestions for fix the issue in code.