VM: allow API testing with different core dependency versions

[holgerd77]

We currently have the problem of a very tight coupling of our monorepo dependencies (see dependency relationship graph for an overview), so that a breaking major release update within one of the monorepo dependencies leads to necessary major release updates in all up-stream library dependants.

This becomes particularly apparent within the VM where most of the libraries are used in conjunction. To ease the coupling here we have discussed to allow for more than one major version of a library to be passed in as an API parameter as one potential solution (and then documented along the function signature).

The newly reworked tx library with the #1048 typed transaction integration (which requires a major tx release v4) is a good candidate for a first application here. To prepare for an integration a test setup should be integrated so that some/all/selected API tests can be run with a different dependency version, e.g. by providing a different package.json file or something.

In our specific case one test scenario is to run the test with the @ethereumjs/tx version 3 from npm, the other scenario is to run - as it is done now - the library with the version from the master branch (respectively a feature branch) (not sure - open for alternative approaches - if it is e.g. significantly easier to run against a to be created ethereumjs/tx/v3 branch or something).

This setup should prepare to execute a test against the VM.runTx() function with on the two runs passing the two mentioned tx versions as a tx parameter to the function.

Old v3 txs should then likely be wrapped early on by a v4 tx with some Tx.fromV3Transaction() function (not necessarily part of this PR).

[holgerd77]

We shifted away here again and instead refocused on not too do breaking releases to often. There is a switch to peer dependencies planned #1200 which should bring some ease here.

Will close.