Resolve all dynamic transaction data when serializing transaction #2156
Description
Every transaction has to be converted to bytes at one point before being sent to the node and that is when we know, for certain, what the contents of the transaction will be. Based on that, instead of setting some dynamic parts of the transaction that depend on other dynamic parts like policies prematurely (e.g. predicateData that depends on the policies count), we should postpone the resolution of the actual dynamic data until the very end when the transaction is being serialized.
By doing this we'd ensure that no conflicts are possible (e.g. predicateData gets set based on one policy count, after which another policy gets added), as well as simplify the transaction encoding logic because there'd be only one place where all the resolution happens.
Caution
This is a major refactoring issue and one should tread carefully in implementing it.