Improve on FunctionInterface parameter type handling

[ezra-sg]

Overview

Presently, only some types of parameters are handled for the Function Interface (accessible via the Contract tab of any /address page for a contract). Users attempting to interact with a contract method using args of type other than uint256 or uint256[x] (fixed-length uint256 array) can result in an error.

Acceptance criteria

• users should be able to enter solidity data of any type using FunctionInterface.vue
• each type of data should get its own input component, including
  • a tooltip should be present explaining the data type and how it should be entered
  • ability to validate data, eg. checking that an address is 20 bytes after parsing (42 chars including 0x)
  • feedback / error message when the user has entered malformed data
• there should be a demo route (eg. /demo/inputs) allowing one to use/test each kind of input

Technical considerations

Related to #102
Also related to #171, which will partially implement address array handling

Because every type must be parsed differently, there should be an input for each type of solidity data. Types resources:
https://docs.ethers.io/v5/single-page/#/v5/api/utils/abi/
https://blog.logrocket.com/ultimate-guide-data-types-solidity/

solidity data inputs will need to be designed as a part of this ticket. we should attempt to use quasar inputs with as few modifications as possible while still meeting the acceptance criteria

for array inputs, we should see if there is a better pattern for entering several items, though any solution must be compatible with the user copy & pasting a full value (rather than only allowing use to type each one by one, and pressing enter to add it to the array)

inputs don't necessarily need masking, just validation

Tasks

• enumerate all valid solidity types and their JS equivalent (e.g. uint256 -> BigNumber)
• determine which types can share an input component (e.g. uint128 and uint256 only vary in valid length) & stub out the expected input components
• determine best approach for complex types such as arrays and arbitrary objects
• determine shared functionality across all input components, e.g. error message, label, placeholder
• implement a BaseFunctionParameterInput with vmodel and above shared functionality
• implement specific inputs one by one
• add a demo route to allow components to be used in isolation, e.g. /test/inputs/
• update the FunctionInterface.vue component to use new inputs

[ezra-sg]

note: verify #86 before closing

[ezra-sg]

#86 seems solved, will close when this work has been merged to master