feat: add mint_with_json

[chadoh]

This uses JSON serialization rather than borsh, which is significantly easier to use from a browser with near-api-js, including providing much better error messaging

[ailisp]

Looks good to me. @nearmax was there a reason to use borsh or to use json serailize, we seem to have a mixed of them in rainbow-bridge-rs contracts

[ailisp]

Also, as all changes before, please don't forget to increase version in package.json :D

[chadoh]

Note: I would rather change mint outright, but adding a new method was an easier way to get erc20-to-nep21 working without breaking existing libraries

If someone wants to modify the main mint function, or replace the token-specific connectors with the generic version in https://github.com/near/rainbow-token-connector (assuming it uses JSON on frontend-facing functions), that would be 10x better

[MaksymZavershynskyi]

JSON serialization of data-heavy objects is very expensive, it might even dominate the cost of the contract for proofs constructed from real headers from Ropsten of Eth Mainnet. We prefer using borsh for this very reason when we are passing headers, proofs and other data-heavy arguments. Alsol the way JSON serializes byte arrays is an array of integers, which is very expensive to parse. CC @Kouprin I don't think it is a good idea to pass it with JSON. Overall, for changes that are suspected to change the gas cost it is recommended to try the contract on the real NEAR node with real data, e.g. proofs from headers on Ropsten or Mainnet.

[Kouprin]

Am I right is affects user experience significantly? More precisely:

1. It's easy to start developing with JSON.
2. For business purposes, it's important to switch to Borsh.

I'd suggest to discuss having both Borsh and JSON ser/deser. Three cons:

1. Easy onboarding because of JSON.
2. We have very limited number of methods that must be Borshified. It will be not too hard to support them.
3. Don't lose possibility to switch to Borsh and save gas.