feat: Add new transaction builder

[DaughterOfMars]

Description

This PR implements an entirely new transaction builder based on experimental changes originally made on the core repository. Fundamentally, this allows a much simpler API in Rust, while also somewhat simplifying the bindings API.

Features

• Simple API for calling basic functions and handling results.
• Methods take simpler types, like &str instead of IdentStr or Identifier.
• Methods use generic types to allow passing many usable data formats.
• Automatic resolution of objects using the client.
• Builder patterns for constructing move calls.
• Any type that implements MoveParams can be used for move call params. Tuples up to length 6 are implemented. Longer param lists can be achieved using nested tuples.
• Custom move types via CustomMoveType (with helper macro move_type!)
• Generic typing rather than constructing TypeTags (via MoveType trait).
• Command results can be bound by a string name, and referenced by later calls with that name using Res.
• Parameters can be passed in directly without fiddling with inputs, and will be automatically handled (via MoveParam trait).
• Mixed parameters (new inputs and named references) can be defined in a single tuple.
• The builder is chainable, except for construction and finishing.

[Alex6323]

What I like about this PR:

• relieves the user of so much boilerplate code (automatic object resolution)
• the NamedCommands chaining by referencing previous results is great
• the implementation is Rust Art imho ❤️ 🦀

What I don't like that much:

• generics make this API very hard to explore without intense study: the former transaction builder may be a bit clunky, but the API clearly told the user what it expects as input arguments. Now if you look at the method signatures you see a lot of trait bounds, but it's not clear at all what you have to pass in. Sure, this can be solved by good documentation, but I fear that for developers this may be intimidating.
• I would remove the dry_run fn from the builder, because although it may be handy to skip the finish method, it's kind of an unexpected API. If you have a TransactionBuilder, I think Rust devs are conditioned to HAVE TO call a finish method at then end. It's still there I know, but I would prefer to enforce this, also because builder.dry_run() reads oddly.
• some naming
• higher complexity of the implementation (builders within builders)
• I don't understand yet the use-case for the TransactionBuilder<()> (non-client type). Maybe it needs examples for that as well to show why it's still useful to have?