Replace bili with rollup

[JGiter]

Description

Currently used bili build tool is poorly maintained. I suppose this is the reason of failing to update dependencies. This PR replaces bili with rollup. In addition of better tool it also provides simpler configuration esm and cjs builds are put in different folders lib and lib.esm, which is common practice

Contributor checklist

• [x] Breaking changes - check for any existing interfaces changes that are not backward compatible, removed method etc.
• [x] Documentation - document your code, add comments for method, remember to check if auto generated docs were updated.
• [x] Tests - add new or updated existed test for changes you made.
• [x] Migration guide - add migration guide for every breaking change.
• [x] Configuration correctness - check that any configuration changes are correct ex. default URLs, chain ids, smart contract verification on Volta explorer or EWC explorer.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.
1 out of 2 committers have signed the CLA.

:white_check_mark: JGiter
:x: renovate[bot]
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[JGiter]

This PR looks like a good start but lib.esm and lib should be added to .gitignore I believe

Yes, build artifacts are happened in root by mistake. I'll output build to dist. And no changes will be needed in .gitignore, because dist already ignored

[JGiter]

This build tested with Switchboard and no issues were found. The only required change is to replace internal imports like here with iam-client-lib/dist/lib.esm/src/modules/signer/signer.types

[jrhender]

The only required change is to replace internal imports like here with iam-client-lib/dist/lib.esm/src/modules/signer/signer.types

Do you think this means that we would need to mark this as a breaking change? On one hand, it is breaking because updating the new version would require code changes and on the other, the code changes would be references to internal file locations which I would say we are free to change.

In the PR description, you wrote:

esm and cjs builds are put in different folders lib and lib.esm, which is common practice

Do you have any documentation/evidence for this being a common or best practice?

[JGiter]

Formally it is not a breaking change because there are neither API nor functional changes. Client code needs to be updated because of improper use of library. Hmm, may be I exaggerated by saying that it is common practice. I just saw such separation in several popular libriries, like ethers or web3

[JGiter]

Something happend to GH. git status says that local is up-to-date with remote, while local is ahead of several commits. Will close and reopen this PR

[JGiter]

Something happend to GH. git status says that local is up-to-date with remote, while local is ahead of several commits. Will close and reopen this PR