Output results of the wasm-decompile to be easier to understand which function is called by call_indirect

The decompiled output from wasm-decompile can be challenging to interpret since the function table is omitted from the resulting files. Annotating the function index within the output aids in comprehending which function is being invoked by the call_indirect instruction.
Consider the following WebAssembly text file, a.wat:

(module
  (type $FUNCSIG$i (func (param i32) (result i32)))
  (table 0 1 funcref)
  (elem (i32.const 0) funcref (ref.func $test))
  (memory $0 1)

  (func $test (type $FUNCSIG$i) (param $p i32) (result i32)
    local.get $p
    i32.const 42
    i32.add
  )

  (func $main (result i32)
    i32.const 42
    i32.const 0
    call_indirect (type $FUNCSIG$i)
  )
)

After running the following commands:

wat2wasm a.wat -o a.wasm
wasm-decompile a.wasm -o a.dcmp

I obtained the decompiled output as such:

memory M_a(initial: 1, max: 0);

table T_a:funcref(min: 0, max: 1);

function f_a(a:int):int {
  return a + 42
}

function f_b():int {
  return call_indirect(42, 0)
}

This decompiled file lacks information about the function table. Moreover, the arguments of the call_indirect function are not immediately clear.
For clearer understanding, consider the decompiled output if it were presented in the following manner:

memory M_a(initial: 1, max: 0);

table T_a:funcref[f_a];

// funcref[0]
function f_a(a:int):int {
  return a + 42
}

function f_b():int {
  return call_indirect(funcref[0])(42)
}

With such modifications, it would be more apparent which function the call_indirect is calling.

Start by reproducing the issue with wat2wasm and wasm-decompile using the a.wat example in the report, then trace how wasm-decompile emits tables, functions, and call_indirect expressions. Done means the decompiled output preserves enough function-table information to identify the indirect target and makes the call_indirect arguments clear, as illustrated in the proposed output.