`tx` tree shaking opportunity -> `TxFactory`

[acolytec3]

Part of #3446

Earliest start together with official breaking release work!

One small opportunity for tree shaking is to convert the existing TxFactory class into a series of single functions that are exported from the tx package or something similar. The class itself serves no essential purpose beyond offering an entry point to the transaction factory. We should pick this up when we get into tree shaking.

[jochem-brouwer]

I'm not entirely sure why this is breaking?

[holgerd77]

This substantially changes how a TXFactory is implemented and the exposed API changes completely, so users will likely adopt to the new methods and can't use their old imports and instantiations anymore.

[acolytec3]

Instead of doing something like TxFactory.fromTxData, it would become simply:

import { fromTxData } from '@ethereumjs/tx'`
//...
const tx = await fromTxData(...txData)

We could consider an alternative approach which is a single txFactory function that accepts either an object of txData, uint8Array (assumes RLP encoded), or else uint8Array[] (assumes "raw" format) and then produces a tx using the correct static constructor from the transaction library

[holgerd77]

One thing to note here, I think this also goes very much along with #3487 and one thing to make sure is that the respective tx type specific not-used from* static constructor methods are tree-shaked out when a specific from* method is used from within the tx factory.

So if e.g. fromTxData() is used from the tx factory that only the create1559TxFromTxData() (or however we name, we should actually align naming here and within the tx type implementations) and the like are kept and the other static constructors (create1559TxFromValuesArray(),...) are thrown out.