Ergonomic error handling mechanism for Fe

### What is wrong?

Although even older smart contract languages like Solidity doesn't support yet handling custom user errors (it's WIP as of today), I'd argue this is a core component that makes a language clean and safe to use (good error handling syntax/semantics). Some projects went as far as writing their own low-level primitives to be able to handle errors efficiently but in a still testable way (i.e., see https://github.com/balancer-labs/balancer-v2-monorepo/pull/417/files). However, such approach is bad for tooling and interoperability in the ecosystem. I suggest this topic to be an important one for Fe so that such problems are avoided from the beginning.

### How can it be fixed

An Idea/suggestion:

Functions that contains revert statements would have a "reverts" keyword in the function signature after the parameters. From call site and looking at this signature, the user knows it is required to use try/catch statements around the specific function. Functions without the revert declaration but containing reverts should fail at compile time (and vice-versa).

I understand that several questions might be raised, i.e., what to do with functions with unknown implementations at compile time etc, but would be good to have it in mind and start this discussion.

Review the proposed `reverts` declaration in function signatures and its interaction with `try/catch` at call sites. Resolve the compile-time rules for functions containing `revert`, including functions with unknown implementations; done means the design questions have a settled specification.

Written by the indexing model from the issue text.