feat(weaver): weaver fabric driver connector implementation

[LordKubaya]

feat(weaver): weaver fabric driver connector implementation

This pull request adds Weaver driver functionality to the Hyperledger Cactus Fabric connector plugin, along with supporting updates to APIs, data models, and tooling.

- Weaver Fabric Driver Implementation:
Integrated the Weaver Fabric driver within the Fabric connector to enable interoperability features and cross-network transactions through the Weaver framework.

- Bufbuild Integration for Protobuf Management:
Added support for Bufbuild to handle existing `.proto` definitions — providing consistent linting, validation, and code generation for Fabric-Weaver communication and easier implementation.

[VRamakrishna]

@LordKubaya We should rename the package cacti-plugin-ledger-connector-fabric (i.e., cactus --> cacti).

Is this just a matter of renaming the folder or will there be several (disruptive) changes required within? If it's the latter, we can do the renaming in a subsequent PR.

[VRamakrishna]

I'd prefer these files not be checked in here (i.e., as part of the Fabric ledger connector package). These protobuf structures were created in Weaver to be commonly used across interoperation pipeline modules and apps, and aren't specific to the Fabric driver.

Ideally, we'd like to expose them through a separate (and dedicated) package, which is what we did in Weaver.

Normally, whenever any of these structures change, a build-and-publish is triggered via GitHub Action for target languages (Go, JS, Java/Kotlin, Rust, Solidity). The respective modules depending on them simply add library dependencies (e.g., in a package.json for a JS/TS code package).

Let's discuss how to avoid having this folder within this package.

[LordKubaya]

@LordKubaya We should rename the package cacti-plugin-ledger-connector-fabric (i.e., cactus --> cacti).

Is this just a matter of renaming the folder or will there be several (disruptive) changes required within? If it's the latter, we can do the renaming in a subsequent PR.

In my opinion, this should be done after this PR.