feat: normalize native token decimals

[gzeoneth]

Was #65 but have decimal stored in bridge instead of inbox & outbox, also rebased the PR on main for fast-track release.

There is a scenario where custom fee token has number of decimals different than 18. That's not ideal because a lot of tooling assumes that native currency (on child chain) is using 18 decimals. For that reason we do a normalization, and de-normalization, when depositing and withdrawing native asset through native bridge.

Ie. let's say deposit amount is 752.

• if token has 16 decimals normalized amount which is going to be minted on child chain is 75200
• if token has 20 decimals normalized amount is 7
• if token uses no decimals normalized amount is 752*10^18

When withdrawing, opposite process is done. There can be loss of precision, due to the fact that we have to round down amount to the nearest supported value.

We also add 2 requirements on the custom fee token in order to avoid overflow:

• fee token can use at most 36 decimals (enforced at inbox/outbox initialization)
• max amount that can be bridged is type(uint256).max / 10**18 which is ~1.1*10^59 tokens

Also use safeApprove in ERC20Inbox.init to support token like USDT that does not return data on approve

[gvladika]

lgtm