Allow pushing an "extra" value in Frame in padding

[dalehamel]

What

Per this comment on the Frame struct:

// Explicit padding bytes that the compiler would have inserted anyway.
// Here to make it clear to readers that there are spare bytes that could
// be put to work without extra cost in case an interpreter needs it.

https://github.com/open-telemetry/opentelemetry-ebpf-profiler/blob/1e5516f97d8b8dea21ad0d9d3f6e126647013fcf/support/ebpf/types.h#L384-L387

This puts those bytes to work by enabling us to pass an additional value in them.

Why

6 bytes is enough for another memory address on x86_64 or aarch64, where they are limited to 48 bits.

https://github.com/torvalds/linux/blob/master/Documentation/arch/arm64/memory.rst

https://github.com/torvalds/linux/blob/master/Documentation/arch/x86/x86_64/mm.rst

Architecture defines a 64-bit virtual address. Implementations can support less. Currently supported are 48- and 57-bit virtual addresses. Bits 63 through to the most-significant implemented bit are sign extended. This causes hole between user space and kernel addresses if you interpret them as unsigned.

Though in practice, we only really see 48 bit addresses for x86_64 and this remains the default.

Specifically, I need this patch to ferry an additional address from BPF to userspace for open-telemetry#907 in order to get accurate line numbers. I'm opening this as a separate PR as I expect these changes to be more controversial.

How

Currently there are 6 bytes of unused padding on the Frame struct. They are present for alignment purposes, but can be used to ferry an additional address to userspace if needed.

This enables _push_with_extra on the BPF side, as well as the code to decode this on the userspace side if it is present. If an interpreter needs the extra address, they use this instead of _push to send the address.

We only encode the value if the extra value is not 0. Likewise, we only decode in userspace it if the first byte is non-zero