Optimise get_config for trivial types

[xunilrj]

Description

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).
  • If my change requires substantial documentation changes, I have requested support from the DevRel team
• 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.

[codspeed-hq]

Merging this PR will improve performance by 10.88%

⚡ 1 improved benchmark
✅ 24 untouched benchmarks

Performance Changes

	Benchmark	BASE	HEAD	Efficiency
⚡	tokens_for_program	655 µs	590.8 µs	+10.88%

Tip

Curious why this is faster? Comment @codspeedbot explain why this is faster on this PR, or directly use the CodSpeed MCP with your agent.

---

_{Comparing xunilrj/opt-get-config (e3c79a8) with master (5184c93)}

[xunilrj]

I think I found the reason for the regressions. This is an example from o2.

get_config before this optimization generates just one ADDI, as apps normally do not have enough configurables to overflow ADDI immediate argument. With the new optimization, on the other hand, apps normally DO have enough bytes in their data section to overflow it, so we end-up with two instructions: MOVI and ADD.

BEFORE

addi $r0 $ssp i1              ; get address of configurable BASE_ASSET

0x00001808 ADDI R52 $ssp 0x1                               ;; [80, 208, 64, 1]

AFTER

addr $r0 data_Configurable_1  ; get address of configurable BASE_ASSET

0x00001630 MOVI R52 0xd30                                  ;; [114, 208, 13, 48]
0x00001634 ADD R52 R52 R63                                 ;; [16, 211, 79, 192]

The regression then occurs when the number of access compensates the gain of removing the decode.

[ironcev]

@xunilrj Regarding the large data section, it is likely we can improve there in general. E.g., I've noticed cases where we have a large number of u64s in the data section: #7612

[xunilrj]

order-book binary size:
Before: 124.56 KB
After: 124.12 KB (0.3% better)

fuel-o2-exports

	Improvements	Regressions
Count	32	1
Average	0.61%	-0.04%
Median	0.64%	-0.04%
Max	1.35%	-0.04%
Min	0.04%	-0.04%