add bpf2go support and wrappers for ebpf.Variable generation

[smagnani96]

This commit introduces support and wrappers around ebpf.Variable.
An ebpf.Variable does not define per-se wrappers method to automatically
infer the underlying data type and handle typed data in Go. In fact, it
relies on parameters passed to the Variable.Get and Variable.Set APIs.
This commit allows bpf2go to emit VariableSpec and Variable in the
generated code. In addition, a new set of wrapper methods are created
to provide support for typed method around variables. To do so, this
commit enables emitting Dataspec, which so far was not emitted. However,
it modifies the current implementation so that for each variable in Dataspec
the needed support is provided.
Supposing to have an ebpf program that defines the following two global variables:

__u64 pkt_count			= 0;
const __u32 ro_variable	= 1;
char var_msg[]			= "Hello World!";

The steps performed during the Go code generation are as follows:

1. An alias with the variable name is generated in the Go file:

type PktCountType 	= uint64
type RoVariable 	= uint32
type VarMsgType 	= [16]int8

2. A new type definition (non-alias, need new methods) for the variables is performed:

type PktCount	ebpf.Variable
type RoVariable	ebpf.Variable
type VarMsg		ebpf.Variable

3. The .Get methods for all types are generated:

func (v *PktCount) Get() (PktCountType, error) {
	var ret PktCountType
	return ret, (*ebpf.Variable)(v).Get(&ret)
}

func (v *RoVariable) Get() (RoVariableType, error) {
	var ret RoVariableType
	return ret, (*ebpf.Variable)(v).Get(&ret)
}

func (v *VarMsg) Get() (VarMsgType, error) {
	var ret VarMsgType
	return ret, (*ebpf.Variable)(v).Get(&ret)
}

4. The .Set methods for the non read-only variables are generated:

func (v *PktCount) Set(val PktCountType) error {
	return (*ebpf.Variable)(v).Set(val)
}

func (v *VarMsg) set(val VarMsgType) error {
	return (*ebpf.Variable)(v).Set(ret)
}

4. In case the type alias is supported by the atomic package, and then
   also supported by ebpf.Variable (int32, uint32, int64, uint64), then
   an additional AtomicRef method is created for the non read-only
   variables to get an reference to the underlying data.

func (v *PktCount) AtomicRef() (*ebpf.Uint64, error) {
	ret, _ := (*ebpf.Variable)(v).AtomicUint64()
	return ret
}

From the user perspective, ignoring the error catching, the following
operations can be performed:

...
objs := bpfObjects{}
err := loadBpfObjects(&objs, nil)
...

// ref kept and can be used multiple times
aPktCount := objs.PktCount.AtomicRef()
vPktCount := aPktCount.Load()
aPktCount.Store(rand.Uint64())
...

vRoVariable, _ := objs.RoVariable.Get()
...

varMsg, _ := objs.VarMsg.Get()
varMsg[0] = 'B'
err := objs.VarMsg.Set(varMsg)

Suggestions/Comments are very welcome. For general discussion, I've opened the issue (:arrow_down:).

This PR relies and is rebased on https://github.com/ti-mo/ebpf/tree/tb/ebpf-variables, not yet merged but planned. Additionally, I'd need the support introduced in my 1st commit 59808a1.

The only new commit that should be referred in this PR is the latest f6a94c5.

My old Variable API proposal prior to https://github.com/ti-mo/ebpf/tree/tb/ebpf-variables are kept here.

Fixes: #1542

[smagnani96]

This PR has been rebased on https://github.com/ti-mo/ebpf/tree/tb/ebpf-variables.
After discussing, @ti-mo proceeds with the Map.Memory() api and the definition of ebpf.Variable, while me (this PR) should provide the needed support for bpf2go.

1. 59808a1 is required but should be introduced in ti-mo updates (open for discussion).
2. f6a94c5 is the commit under review.

[mejedi]

It probably makes sense to land basic bpf2go variable support first:

• VariableSpecs included in generated xxxSpecs; do we need to segregate them similar to today's xxxProgramSpecs/xxxMapSpecs?
• Variables included in generated xxxObjects.

I see huge value in a type-safe get/set API you are proposing. It would be nice to have not only Variables covered, but probably VariableSpecs, and Maps, and MapSpecs as well.

Is it possible to devise an approach that works with Variables initially, but can be extended for other object kinds later? Can we generate less code by using generics?

[smagnani96]

It probably makes sense to land basic bpf2go variable support first:

• VariableSpecs included in generated xxxSpecs; do we need to segregate them similar to today's xxxProgramSpecs/xxxMapSpecs?
• Variables included in generated xxxObjects.

I see huge value in a type-safe get/set API you are proposing. It would be nice to have not only Variables covered, but probably VariableSpecs, and Maps, and MapSpecs as well.

Is it possible to devise an approach that works with Variables initially, but can be extended for other object kinds later? Can we generate less code by using generics?

Do you suggest to change this PR to provide basic VariableSpecs support in bpf2go or should I open a new one?

Concerning the type-safe API, I can keep exploring solutions. I tried with generics with no luck, but maybe there's still a way...AFAIU CollectionSpec would also need to be a generic holding maps and variables each of different generic types.