Big string / big record support

[danobi]

Take, for example, this:

  $ sudo ./build/src/bpftrace -e 'BEGIN { print(*curtask); exit() }'
  error: <unknown>:0:0: in function BEGIN i64 (ptr): A call to built-in function 'memset' is not supported.

The reason is curtask dereference puts the entire struct on the stack.
Which not only doesn't fit, but does not qualify for unrolled memset builtin.

One potential way to handle this is to use the new createGetScratchMap()
infrastructure to "allocate" memory in unop_ptr() instead of from the stack.

But the drawback is that we can only have a single live allocation at a time.
Meaning, something like this would not be possible:

  $one = *curtask;
  $two = *curtask;
  print(($one, $two));

However, something like this could be possible:

  $one = *curtask;
  print($one);
  $two = *curtask;
  print($two);

That is b/c in the second example the lifetimes of $one and $two are disjoint.

I think above is a good starting point for big string / big record support.
We can do some basic lifetime analysis in semantic analyser (or a new pass?)
and error out if there's overlap.

In the future we can allocate as many scratch maps as we need (perhaps up
to a certain limit).

I'm not sure I've covered all the cases. But I think this is something good
to think about.

[danobi]

Could create a scratch-map per big-string/big-record. It's a bit wasteful but we won't need to do lifetime analysis.

Another option is to disallow storing big-string/big-records on the stack. So for example, only allow them to be copied into maps or output ring buffers.

[danobi]

We'll tackle the memset() issue in #3229. Big record support is rather esoteric, so we can address that if users ever ask for it