Optimize tx module for bytecode size and gas usage

[ironcev]

Description

This PR optimizes functions in the tx module for bytecode size and gas usage. E.g., the bytecode size of the following script that calls all of the optimized functions got reduced from 1792 bytes to 648 bytes:

fn main() {
    let _ = std::tx::tx_script_length();
    let _ = std::tx::tx_script_data_length();
    let _ = std::tx::tx_script_data::<u64>();
    let _ = std::tx::tx_script_bytecode::<u64>();
    let _ = std::tx::tx_script_bytecode_hash();
    let _ = std::tx::tx_witnesses_count();
    let _ = std::tx::tx_witness_data::<u64>(0);
}

The optimization:

• mostly removes the duplicated checks for tx_type() and where necessary, replaces calls to tx_type() to a single if.
• removes the private helper function tx_script_start_pointer. The function was re-checking the tx_type() to be a script, although always being called only if the tx_type was already checked for being a script. Additionally, it was wrapping the result in Option requiring an additional unnecessary indirection.
• removes the private helper function tx_script_data_start_pointer for similar reasons.
• rewrites tx_witness_data by removing unnecessary length calculation and duplicated code.
• simplifies match expressions by replacing duplicated match arms with a single arm.

The PR introduces a slight change in the semantics of functions like, e.g., tx_script_length that return Option. Before, if the tx_type was Mint they would panic instead of returning None. Now they return None. The new behavior actually looks like the proper one to me. A function returning Option shouldn't panic.

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.