chore: seal traits

[MujkicA]

Following the discussions around #1244 I figured we could still benefit from sealing some of our public traits.
The benefit is that adding new methods to these traits will not cause a breaking change:

Transaction
TransactionBuilder
BuildableTransaction
EstimablePredicates
GasValidation

I've wondered wether Account is a trait where downstream implementations would make sense. I came up with a potential example of a joined account here. The current way to implement it is a bit clunky, especially because signing would require some kind of internal state to keep track of what accounts actually contributed to the input set. But if this is a a valid use case, we could consider improving the interface.

Checklist

• I have linked to any relevant issues.
• I have updated the documentation.
• I have added tests that prove my fix is effective or that my feature works.
• I have added necessary labels.
• I have done my best to ensure that my PR adheres to the Fuel Labs Code Review Standards.
• I have requested a review from the relevant team or maintainers.

[segfault-magnet]

Account is the only one that I'm not sure about.

I'm fine with whatever you choose. If you seal it and in hindsight it turns out to be a mistake, we can always unseal it.

If you don't seal it and we make a breaking change -- we're still able to breaking changes so fine again.

The use case you cited is interesting. As long as sealing Account doesn't prevent a use case for the sdk I'm ok with sealing it. The user can always manually create a transaction and fund it however he wishes.

[iqdecay]

lgtm

[digorithm]

Neat little design pattern; I love it.

Now, for Account... maybe we shouldn't. I really liked the idea of joint accounts and enabling the users to implement those. 🤔