Consider to encode certain reverts (e.g. abi decoding / input validation errors) as `Error(uint256)` with defined error codes

## Abstract

Consider to encode certain reverts as `Error(uint256)` with defined error codes

## Motivation

Both Solidity and Fe currently use `Panic(uint256)` to encode certain reverts with different panic codes as [defined in the documentation](https://docs.soliditylang.org/en/v0.8.6/control-structures.html?#panic-via-assert-and-error-via-require).

However, there are certain reverts around decoding of invalid abi encoded data for which Solidity reverts with zero data.
[Fe](http://fe.ethereum.org/) currently encodes these reverts as `Panic(uint256)` with panic code `0x99`.

But as @ekpyron pointed out `Panic(uint256)`was meant for a different category of failures.

Citing @ekpyron

>short summary is: panics, which have the panic codes, were introduced to replace "asserts", resp. "this should never happen" situations, while decoding invalid abi encoded data has to be expected to happen and rather falls into the category of "require" errors... which is why they weren't covered in the panic codes

The Fe team wants to avoid reverting with zero information to improve the developer experience. The Fe team is quite happy to re-align to a different encoding if the Solidity teams want to start encoding these reverts differently.

We briefly discussed using the signature `Error(uint256)` for this category of errors and the purpose of this issue is to find out if that would be a favorable way forward for this category of errors.

No source files, tests, or entry points are identified in the issue. Start by reviewing the discussion and the linked Solidity panic/error documentation; done requires agreement on whether Error(uint256) and defined codes are the preferred encoding for these reverts.

Written by the indexing model from the issue text.