[v5.x] Optimised module structure

[aslesarenko]

This issues describes the motivation and proposal for possible optimisation/modularisation of codebase.
The modularisation is mostly necessary for better JS packaging, but having separate JVM artefacts (jar files) may be also valuable. On server side it is less of an issue and both Android and RoboVM (which is used for iOS) extract only necessary classes for jars during app packaging.

For JS, however, in terms of size, the fullOptJS command generates
2.1MB main.js for sc module (full package)
1.4 MB main.js for sdk module without compiler

Such sizes lead to observable glitches in UI loading.

The single main.js can be further split into the following:

1. core module - Support for ReducedTransaction serialisation and signing (enough for ErgoPay). This will not include reduction of transaction and hence ErgoTree serialisation and interpreter will not be necessary. The size of core will be small. Deals with secrets and can be used in wallets and dApps.

2. cryptomodule (depends on core) - implements multi-signing of arbitrary ReducedTransaction. Should be used in wallets and dApps. Deals with secrets and can be used in wallets and dApps.

3. interpreter module (depends on core) - Reduction of UnsignedTransaction to ReducedTransaction, contains ErgoTree serialises and interpreter. Doesn't work with secrets, can be used at any backend.

4. sdk module (depends on interpreter) - contains components not included in interpreter (such as basic wallet operations with EIP3 addresses excluding operations with mnemonics). Doesn't work with secrets, can be used at any backend.

5. sc module (depends on sdk) - compiler and related code. Doesn't work with secrets, can be used at any backend.

The idea of this split is to separate core and crypto modules, from ErgoTree interpreter and compiler.
The core and crypto modules provide all the necessary support of ReducedTransaction. Thus they will be enough for ErgoPay support in the wallets.

This module structure will require another rounds of code reorganisation in Sigma, which will only make sense if it will be reused across JVM and JS projects uniformly.
In particular, the same modules can be published for both JS and JVM as separate libraries, so Java/Kotlin projects can use only what they need.

For example:

• wallets - can use only core + crypto for ReducedTX signing (including multisig)
• dApp - can use core + interpreter if they only use pre-compiled contract templates
• Dev Tools - can use core + interpreter + sc to compile contracts and run interpreter in simulated environment
• Ergo Node - can use core + interpreter + sdk - to validate transactions and for embedded wallet.
• etc.