btf: export DeclTag and TypeTag

[dylandreimerink]

This commit makes the TypeTag BTF type exported. It had not been
exported because it was lumped in with the DeclTag type. However,
no modification to the codebase seems to be needed to accommodate
the usage of TypeTags.

This commit makes the DeclTag BTF type exported. The DeclTag has been
unexported because its encoding is a bit tricky.

DeclTags on the wire refer to a type by its ID, and an component index.
Unlike other BTF types, the type ID isn't always the actual "target",
instead if the component index is not `-1` it targets a child object of
the type. This commit adds a `Tags` field to all types that can have
DeclTags including Members.

Exception is function parameters. Due to the func -> funcProto ->
parameter encoding, it is possible that BTF deduplication reuses the
same funcProto for multiple functions. The declTags point to the func to
annotate the arguments. Thus, adding a `Tags` field to Param would
cause inaccurate BTF marshalling. Instead, a `ParamTags` field is added
the func as `[][]string` to match the write format more closely to
avoid issues caused by BTF deduplication. This is a compromise between
technical feasibility and user experience. Users need to manually match
up the `ParamTags` with the `Params`. This shouldn't be a huge issue
in most cases however.

This means we now effectively have less "types" in our Go BTF
representation then we have on the wire since declTags become strings
on other types. This might leave "holes" in our BTF type numbering
if we were to remove them. So instead we leave the `declTag` types in
the BTF type list, but we hide them from the user during iteration.
Technically, users can still access them by ID if they know the ID, but
like before this commit, the returned value can only be printed.

Marshalling relies on the iteration of the BTF types. When go to load
a BTF blob from a collection, we iterate from a collection of root types
which are directly used. This causes us to load only BTF info that is
actually in use. This commit introduces a trick into the `children`
logic used during iteration. When we iterate over a type with declTags,
we create internal `declTag` types at-hoc with the correct component
index. So even though the tags are just strings on other types, when
iterating they appear as actual types. This causes only declTags that
are on types which are in use to be marshalled.

[mejedi]

It looks like .copy methods on nodes should copy .Tags. Apparently, children function powers both marshalling and deep copying. In the context of deep copying, creating and yielding declTags is not strictly necessary.

[ti-mo]

Awesome! Left a few comments, haven't looked at the tests in-depth.

[mejedi]

It looks like .copy methods on nodes should copy .Tags. Apparently, children function powers both marshalling and deep copying. In the context of deep copying, creating and yielding declTags is not strictly necessary.

Submitted a follow-up to handle .Tags in .copy: #1582