Standardize panic codes across the std-lib for enhanced error messages in the SDK

[Voxelot]

We should identify all common cases for panics in the std-lib and assign preset panic codes to each case. This will enable the SDK to provide more user friendly errors and help developers when troubleshooting.

For example, when trying to read a storage value that isn't properly initialized the user will receive an error like this when using the SDK:

thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: RevertTransactionError { reason: "Revert", revert_id: 0, receipts: [Call { id: 0000000000000000000000000000000000000000000000000000000000000000, to: 70cffda39ba9336d72547d84619423bdaa132c63b05827573b83c6796e5d5fb0, amount: 0, asset_id: 0000000000000000000000000000000000000000000000000000000000000000, gas: 1000000, param1: 3846424166, param2: 1, pc: 11632, is: 11632 }, Revert { id: 70cffda39ba9336d72547d84619423bdaa132c63b05827573b83c6796e5d5fb0, ra: 0, pc: 12180, is: 11632 }, ScriptResult { result: Revert, gas_used: 412 }] }', src/main.rs:32:10

If we had a special panic code for this particular case, the SDK should then match against the panic code and return a more user friendly error such as StorageValueUninitialized.

This task will involve some research into documenting all std-lib panic cases and assigning codes that are unlikely to conflict with most dapps. We could even specify a reserved range of panic codes for the std-lib and warn developers at compile time if they are reusing the same codes that are used for the std-lib.

cc @FuelLabs/application-dev @FuelLabs/sdk-rust @FuelLabs/sdk-ts

[SwayStar123]

Would allowing users to extend this to their projects errors be possible aswell?

[Voxelot]

Looking more closely at how errors are handled in solidity, we may want to move this to an RFC discussion to support a less hardcoded approach here.

In solidity, you can specify any error string you want for a require. These error strings are hashed and outputted to a separate file by the compiler tooling (e.g. hardhat). When the panic opcode happens, solc uses the hashed representation of the error string to keep the receipt a fixed size, and then the sdk uses the autogenerated panic code -> error string mapping to return the user friendly error message.

While our panics only support a u64 instead of a full b256, we could likely implement a similar mechanism in the compiler to automatically assign a unique u64 to each error string.