Add GTF_OUTPUT_COIN_ASSET_ID and GTF_OUTPUT_COIN_TO opcode getters

[bitzoic]

Description

Added getters for the GTF_OUTPUT_COIN_ASSET_ID and GTF_OUTPUT_COIN_TO opcodes. These have been highly requested by external teams for use in predicates.

Note: The output_asset_to() getter currently returns a b256 rather than an Identity. This should be updated when #4569 is resolved.

Checklist

• I have linked to any relevant issues.
• I have commented my code, particularly in hard-to-understand areas.
• I have updated the documentation where relevant (API docs, the reference, and the Sway book).
• I have added tests that prove my fix is effective or that my feature works.
• I have added (or requested a maintainer to add) the necessary Breaking* or New Feature labels where relevant.
• I have done my best to ensure that my PR adheres to the Fuel Labs Code Review Standards.
• I have requested a review from the relevant team or maintainers.

[K1-R1]

Changes seem fine, but CI is failing

[Braqzen]

1. In the setup the wallet transfers 2 assets. Do we need to transfer the second asset to the predicate prior to testing or can that transfer be removed?
2. When unpacking variables from the setup function in the tests I would use the same variable names throughout instead of sometimes using wallet and then wallet1 etc.

[bitzoic]

1. In the setup the wallet transfers 2 assets. Do we need to transfer the second asset to the predicate prior to testing or can that transfer be removed?
2. When unpacking variables from the setup function in the tests I would use the same variable names throughout instead of sometimes using wallet and then wallet1 etc.

1. This is a setup function. It is setting up. As more GTFopcodes come online this will be needed.
2. This is done in tests to purposely create distinctions. Nothing is more frustrating than seeing a test fail and not know why because all the variables are named the same.

[Braqzen]

1. In the setup the wallet transfers 2 assets. Do we need to transfer the second asset to the predicate prior to testing or can that transfer be removed?
2. When unpacking variables from the setup function in the tests I would use the same variable names throughout instead of sometimes using wallet and then wallet1 etc.

1. This is a setup function. It is setting up. As more GTFopcodes come online this will be needed.
2. This is done in tests to purposely create distinctions. Nothing is more frustrating than seeing a test fail and not know why because all the variables are named the same.

1. It's a bad practice to add code in anticipation of future features unless you are about to work on those features soon because it creates technical debt as priorities change and the code sits there indefinitely. As things change there is more maintenance on top of polluting the current PR with code that does not serve a function (and thus it should be added later).
2. It's fine to have different names. I'm referring more towards consistency. For example, the last 2 tests that revert use 2 different variable names for the asset. In the top test the 2nd variable is called asset_id when it should be called asset_id2 thus validating the name asset_id1 in the lower test in the first position. Similarly for any other variable names

[bitzoic]

1. In the setup the wallet transfers 2 assets. Do we need to transfer the second asset to the predicate prior to testing or can that transfer be removed?
2. When unpacking variables from the setup function in the tests I would use the same variable names throughout instead of sometimes using wallet and then wallet1 etc.

1. This is a setup function. It is setting up. As more GTFopcodes come online this will be needed.
2. This is done in tests to purposely create distinctions. Nothing is more frustrating than seeing a test fail and not know why because all the variables are named the same.

1. It's a bad practice to add code in anticipation of future features unless you are about to work on those features soon because it creates technical debt as priorities change and the code sits there indefinitely. As things change there is more maintenance on top of polluting the current PR with code that does not serve a function (and thus it should be added later).
2. It's fine to have different names. I'm referring more towards consistency. For example, the last 2 tests that revert use 2 different variable names for the asset. In the top test the 2nd variable is called asset_id when it should be called asset_id2 thus validating the name asset_id1 in the lower test in the first position. Similarly for any other variable names

1. This is used now, not something in the future.
2. Updated to asset_id2