Strong type support for Eth API

[nazarhussain]

Description

THis PR provides strong type support for Eth API with flexible API syntax for better maintenance.

Fixes #4520

Type of change

• New feature (non-breaking change which adds functionality)

Checklist:

• I have selected the correct base branch.
• I have performed a self-review of my own code.
• I have commented my code, particularly in hard-to-understand areas.
• I have made corresponding changes to the documentation.
• My changes generate no new warnings.
• Any dependent changes have been merged and published in downstream modules.
• I ran npm run dtslint with success and extended the tests and types if necessary.
• I ran npm run test:unit with success.
• I ran npm run test:cov and my test cases cover all the lines and branches of the added code.
• I ran npm run build and tested dist/web3.min.js in a browser.
• I have tested my code on the live network.
• I have checked the Deploy Preview and it looks correct.
• I have updated the CHANGELOG.md file in the root folder.

[spacesailor24]

eth_getCompilers is missing from new spec, created an issue

[nazarhussain]

@jdevcs In reference to all feedback related to Execution API spec.

• EthExecutionAPI is not enforced anywhere, rather used as default value of the generic.
• The consumer of the providers can pass any APISpec for generic to use any other API.
• The API Spec design also not enforce Eth pattern, rather JSON-RPC standard. As soon one consume any JSON-RPC compatible API, one can use same provider without any issue with same type safety.
• As already discussed we will move EthExecutionAPI to the web3-eth package in up-coming PRs. That will also resolve the separation of concern.