solana: Multi Transceiver Support

[nvsriram]

• Refactor src/transceivers/* and src/messages.rs from Manager into ntt-transceiver program
• Add zero-copy deserialization helpers for ValidatedTransceiverMessage in Manager
• Update transceiver's release_outbound ix to CPI into Manager's mark_outbox_item_as_released ix.
• Update Makefile to remove generics (if exists) from all programs
• Bump IDL to version 3.0.0

[nvsriram]

SDK currently doesn't support multi-transceiver (it takes in a transceiver address at initialization and doesn't use it after that). Current TS changes are the minimum necessary to be able to test a custom transceiver.
However a proper refactor considering backwards compatibility and multi-transceiver support would be necessary.

One potential solution is to add a map/list for transceivers in the SolanaNtt class instead of the whTransceiverAddress. As a consequence, the getTransceiver function, SolanaNttWormholeTransceiver class, etc. would all need to be updated.

[kcsongor]

One potential solution is to add a map/list for transceivers in the SolanaNtt class instead of the whTransceiverAddress. As a consequence, the getTransceiver function, SolanaNttWormholeTransceiver class, etc. would all need to be updated.

this would be the most comprehensive solution, but might make sense to tackle it in a separate PR

[nvsriram]

One potential solution is to add a map/list for transceivers in the SolanaNtt class instead of the whTransceiverAddress. As a consequence, the getTransceiver function, SolanaNttWormholeTransceiver class, etc. would all need to be updated.

this would be the most comprehensive solution, but might make sense to tackle it in a separate PR

That makes sense, I'll make a new PR that is based on this to implement the TS SDK refactor. At the end, we can merge both PRs together.

[nvsriram]

One potential solution is to add a map/list for transceivers in the SolanaNtt class instead of the whTransceiverAddress. As a consequence, the getTransceiver function, SolanaNttWormholeTransceiver class, etc. would all need to be updated.

this would be the most comprehensive solution, but might make sense to tackle it in a separate PR

That makes sense, I'll make a new PR that is based on this to implement the TS SDK refactor. At the end, we can merge both PRs together.

The TS SDK refactor is complete (with all CI jobs accounted for) and the PR is ready for review: #535 🎉

I think it makes chronological sense to review this PR first and then the TS SDK refactor PR as those changes are based off this.