Benchmarks for address-lookup-table program instructions

[tao-stones]

Problem

Part of #3364, to benchmark each address-lookup-table instructions to determine their static CU consumption.

Summary of Changes

add benches for each instruction, aiming to run through their happy-path.

Fixes #

[tao-stones]

local bench results

Running benches/address_lookup_table.rs (target/release/deps/address_lookup_table-972fa07f59235041)
create_lookup_table     time:   [11.539 µs 11.551 µs 11.562 µs]
                        change: [-6.7516% -6.5123% -6.2789%] (p = 0.00 < 0.05)
                        Performance has improved.
Found 1 outliers among 100 measurements (1.00%)
  1 (1.00%) high severe

extend_lookup_table     time:   [8.5900 µs 8.6005 µs 8.6130 µs]
                        change: [-2.9621% -2.7085% -2.4662%] (p = 0.00 < 0.05)
                        Performance has improved.
Found 1 outliers among 100 measurements (1.00%)
  1 (1.00%) high mild

freeze_lookup_table     time:   [6.5421 µs 6.5688 µs 6.5953 µs]
                        change: [-2.2161% -1.8525% -1.4759%] (p = 0.00 < 0.05)
                        Performance has improved.

deactivate_lookup_table time:   [6.6263 µs 6.6394 µs 6.6535 µs]
                        change: [-2.2693% -1.8627% -1.4637%] (p = 0.00 < 0.05)
                        Performance has improved.
Found 8 outliers among 100 measurements (8.00%)
  1 (1.00%) low severe
  5 (5.00%) low mild
  2 (2.00%) high mild

close_lookup_table      time:   [6.5578 µs 6.5719 µs 6.5850 µs]
                        change: [-2.0988% -1.8293% -1.5879%] (p = 0.00 < 0.05)
                        Performance has improved.
Found 8 outliers among 100 measurements (8.00%)
  1 (1.00%) low mild
  7 (7.00%) high mild

[KirillLykov]

looks good to me overal

[KirillLykov]

using numbers to index accounts rather than at least named constant makes it fragile in case of code modifications.

[tao-stones]

yea agree, thanks for good suggestion! can refactor it separately.