Consider whether to allow typed `bytesX` function arguments

[mr-zwets]

Created a standalone issue for typed bytesX function arguments

previously part of #178 (previously titled 'Consider changes to bytes types)

Mathieu and I were talking about this and we think it could make sense to disallow bytesX as function parameters, since these types are not runtime enforced. We could alternatively also add an option to enforce these types by injecting require(x.length === y) statements. This is something we should consider in more detail later.

For bytesX types in function parameters:

1. We disallow bytesX as function argument.
2. If a user adds e.g. a require(x.length == 20) check, then the compiler will infer that x's type is bytes20 for the rest of the contract.
3. (Optionally) apply the same for if statements.
4. If people want to forgo these checks, they can always manually cast to bytesX(x). We should add a warning to the docs about the security implications of doing that.

this issue also came up when thinking about how to integrate structs (#27)

[mr-zwets]

I looked into the implementation details a bit to disallow the byte and byteX semantic types in function arguments, we have 2 broad strategies

1. either we update visitFunctionDefinition in EnsureFinalRequireTraversal.ts to disallow these semantic bytes types
2. or we could change the language definition types for functions in CashScript.g4

with reusable functions in mind i prefer 1 over 2 I think.

Then to get the type inference on the require check we'd need new logic in visitRequireStatement

[mr-zwets]

a good argument for doing hidden checks on the unlocking arguments is that this works well with more complex types in the future like fixed size arrays. Solidity also does hidden checks that the provided types for unlocking arguments are correct.