Error linking binaries with differing e_flags.

Error linking binaries with differing e_flags.

This commit is partly changing two existing (believed buggy) behaviours
in elfNN_aarch64_merge_private_bfd_data and partly accounting for a
capability-specific requirement.

The existing behaviours in elfNN_aarch64_merge_private_bfd_data were:
1) It returned `TRUE` by default.  This effectively ignored the ELF
   flags on the binaries, despite there being code looking at them.
2) We do not mark the output BFD as initialised until we see flags with
   non-default architecture and flags.  This can't tell the difference
   between linking default objects to non-default objects if the default
   objects are given first on the command line.

The capability-specific requirement is:
- This function originally returned early if the object file getting
  merged into the existing output object file is not dynamic and has no
  code sections.  The code reasoned that differing ELF flags did not
  matter in this case since there was no code that would be expecting
  it.
  For capabilities the binary compatibility is still important.
  Data sections now contain capabilities as pointers, got sections now
  have a different got element size.
  Hence we avoid this short-circuit if any of the flags we're checking
  are the CHERI_PURECAP flag.