OAv2 merge: merging Object Attributes

OAv2 merge: merging Object Attributes

The Object Ottributes merge process must handle both optional and
required subsections. It also treats the first merge of the frozen set
specially, as the OAv2 list in the input BFD serves as the accumulator
for subsequent merges.

** Optional subsections

Optional subsections are processed as if merging two ordered sets — by
iterating linearly through both, checking whether an element of a given
ordinality is present in the opposite set, and adding it to the
accumulator. The added diffuculty with subsections and attributes lies
in the fact that missing elements have default values, and these must be
merged with existing ones to produce the final value to be stored.

** Required subsections

Required subsections are processed slightly differently from the
optional subsections, as they cannot be pruned since they are mandatory,
hence an error will be raised by the linker if it is not recognized.

For now, the subsection for PAuth ABI is the only one use case, and
no merge is applied on the values. The values simply need to match.
This implementation choice might be challenged in the future if required
subsections can have the same diversity as optional subsections. If the
case arises, the refactoring to handle this new behavior should consist
in adding a new merge policy MERGE-EQUAL, or something similar. Some "if
required" should be added in the optional subsections merge logic to
error on any missing elements, or mismatch, and messages should also be
rephrased to point out that the error is for a required subsection.

** Important note regarding support for testing

In order to test this generic logic, AArch64's use cases are not
offering enough coverage, so a "GNU testing namespace" which corresponds
to the name of the subsection was introduced. It follows the following
pattern:
  gnu_testing_<XXXXXX>_MERGE_<POLICY>
with:
  - <XXXXXX>: an arbitrary name for your testing subsection.
  - <POLICY>: the name of the merging policy to apply on the values in
    the subsection. The currently supported merge policy are:
      * _MERGE_AND: bitwise AND applied on numerical values.
      * _MERGE_OR: bitwise OR applied on numerical values.
      * _MERGE_ADD: concatenates strings together with a '+' in-between.
    Note: "_MERGE_ADD" does not make really sense, and will very likely
    never be used for a real merge. Its only purpose is to test the
    correct handling of merges with strings.
Any subsection name matching neither names supported by the backend, nor
following the pattern corresponding GNU testing namespace will be considered
unknown and its status set to obj_attr_subsection_v2_unknown. This will
have for consequence the pruning of this subsection.

Additionally, the first two tags in gnu_testing namespace, GNUTestTag_0
and GNUTestTag_1, are known, and so have a name and can be initialized
to the default value ('0' or NULL) depending on the encoding specified
on the subsection. Any tags above 1 will be considered unknown, so will
be default-initialized in the same way but its status will be set to
obj_attr_v2_unknown. This behavior of the testing tags allows to test
the pruning of unknown attributes.