Assign correct stack_type to map

[fbs]

The type of a map gets determined the first time something gets assigned
to it. As the arguments to kstack/ustack only get evaluated in the
last pass the map will be created with the default stack type, not the
one specified by the user.
Due to the way stacks work, with the hidden stack map and the user map
that holds the stack id, this only shows up when trying to print the
map. The type associated with the user map has the correct stack type,
but the original map has the default. This eventually leads to a SEGV.

Simple repro:

'i:s:1 { $a=10; @=kstack(perf); exit(); }'

Thread 1 "bpftrace" received signal SIGSEGV, Segmentation fault.
0x000000000046475a in bpftrace::BPFtrace::get_stack[abi:cxx11](...)
1680	  int err = bpf_lookup_elem(maps[stack_type].value()->mapfd_,
(gdb) p stack_type
$1 = {limit = 127, mode = bpftrace::StackMode::bpftrace}`

As this call expects literals we don't have to worry about variables and
thing that might be evaluated later, so we can just remove the
is_final_pass() check.

This fixes #1523

Checklist

• User-visible and non-trivial changes updated in CHANGELOG.md
• The new behaviour is covered by tests

[fbs]

bpftrace -e 'i:s:1 { @a=kstack(perf); @b=kstack(bpftrace) }'
Attaching 1 probe...
^C

@a:
	ffffffff9fca5cae native_safe_halt+14
	ffffffff9f23d7a5 arch_cpu_idle+21
	ffffffff9fca5e53 default_idle_call+35
	ffffffff9f2d8fcb do_idle+507
	ffffffff9f2d91d0 cpu_startup_entry+32
	ffffffff9fc988de rest_init+174
	ffffffffa0a99c77 arch_call_rest_init+14
	ffffffffa0a9a1fe start_kernel+1380
	ffffffffa0a9944a x86_64_start_reservations+36
	ffffffffa0a994c1 x86_64_start_kernel+117
	ffffffff9f2000d4 secondary_startup_64+164

@b:
        native_safe_halt+14
        arch_cpu_idle+21
        default_idle_call+35
        do_idle+507
        cpu_startup_entry+32
        rest_init+174
        arch_call_rest_init+14
        start_kernel+1380
        x86_64_start_reservations+36
        x86_64_start_kernel+117
        secondary_startup_64+164

[grooverdan]

worked for me. Thank you very much.

[fbs]

Ready for review. I'll fix the changelog when it has some approvals