Make necessary refactoring to enable no_std support

[digorithm]

Due to many issues with the current way we were enabling no_std support on fuels-rs, we had to revert and remove no_std support for now. Previous versions will still work normally.

However, we still want to enable no_std to some parts of fuels-rs that are needed as no_std, such as the Fuel's indexer. This will require some major refactoring/reorganization in order to make it more no_std friendly.

Some parts that need to be included as no_std:

1. The code that gets emitted from wasm_abigen;
2. ABIDecoder;
3. Token, Tokenizable, ParamType, and related dependencies.

[adlerjohn]

@mitchmindtree are you still planning on working on this?

[mitchmindtree]

Ahh apologies, I intended to look into it as a way to get started but have been consumed by forc stuff :) I'll unassign myself in case anyone else would like to take this on!

[adlerjohn]

@digorithm are you still planning on working on this? 😂

[digorithm]

To be honest, only if/when it's actually needed. There are so many more higher priority items that this one is way lower in priority. Of course its priority would change if it becomes a blocker to someone.

Since we removed no_std support I haven't heard any requests for it, so I'm assuming it's not needed at the moment.

[Voxelot]

It's causing circular dependency issues between fuel-core and fuel-indexer, and fuel-indexer is stuck on an outdated version of fuels-rs (v0.2) until this is resolved. We can potentially get someone from the client team to look into this if you don't have bandwidth.

[mitchmindtree]

Closing this in favour of #317 as we've discovered fuel-indexer doesn't need #![no_std], but rather needs the ability to compile to the wasm target. It's a similar problem, but hopefully quite a bit easier to address. Edit: Actually after a closer look #317 doesn't really cover this - I'll open a dedicated issue.

[mitchmindtree]

I've opened #318.