[Feature]: Generalize the API for the `catalyst_cardano_serialization` package to Enhance Flexibility and Compatibility

[ilap]

Feature Title

Generalize the API for the catalyst_cardano_serialization package (CBOR and other Encodings)

Feature Description

The goal of the catalyst_cardano_serialization package is to generate an unsigned transaction CBOR that can be signed and submitted to the blockchain. The package does not communicate with the wallet or the blockchain, so signing and submission are outside its scope.

1. Use an Interface for CBOR Encoding: Implement an interface for CBOR encoding/decoding, such as:

   abstract class CborEncodable {
   CborValue toCbor();
   }

   This would standardize the way CBOR is handled across different classes, allowing for more consistent and flexible encoding and decoding.

Use Case

The proposed feature will enhance the flexibility and extensibility of the catalyst_cardano_serialization package. By handling CBOR encoding/decoding more efficiently.

Is this a modification to an existing feature? Yes

[dtscalac]

Hello @ilap, very well written proposals. All three of them are valid and welcome. To make tracking simpler consider to split the issue into 2-3 issues, each point as a separate issue. Alternatively you can combine points 1 and 2 into one and 3rd as a separate one?

Long term goals are to fully support smart contracts and other transaction body fields but there are currently other priorities. If you need that urgently consider contributing to the project.

You can find a great source for inspiration at: https://github.com/dcSpark/cardano-multiplatform-lib

[ilap]

Alternatively you can combine points 1 and 2 into one and 3rd as a separate one?

Good idea, I will split the issues.

Long term goals are to fully support smart contracts and other transaction body fields but there are currently other priorities. If you need that urgently consider contributing to the project.

I don't currently have a need for this feature, as I was just exploring the package and it caught my attention. Though, I am open to contributing to the project, for example by refactoring the TransactionOutput class to handle pre-Babbage and post-Alonzo outputs as a start.

You can find a great source for inspiration at: https://github.com/dcSpark/cardano-multiplatform-lib

Yeah, but it seems to me too complex that could be implemented in much simpler way. Also, I think the api of the TransactionBuilder class should be defined first, meaning what the users would like to have or needed for handling complex scenarios with a fully featured transaction.

[dtscalac]

@ilap can you please report a new issue for generalizing signing methods? The CborEncodable has been introduced in #696 already, I'm closing this issue as in general we want to track each problem in separate issues.