Revert "[AArch64][BZ #17711] Fix extern protected data handling"

Revert "[AArch64][BZ #17711] Fix extern protected data handling"

This reverts commit 0910702c4d2cf9e8302b35c9519548726e1ac489.

Say both a.so and b.so define protected data symbol `var` and the executable
copy relocates var.  ELF_RTYPE_CLASS_EXTERN_PROTECTED_DATA has strange
semantics: a.so accesses the copy in the executable while b.so accesses its
own.  This behavior requires that (a) the compiler emits GOT-generating
relocations (b) the linker produces GLOB_DAT instead of RELATIVE.

Without the ELF_RTYPE_CLASS_EXTERN_PROTECTED_DATA code, b.so's GLOB_DAT
will bind to the executable (normal behavior).

For aarch64 it makes sense to restore the original behavior and don't
pay the ELF_RTYPE_CLASS_EXTERN_PROTECTED_DATA cost.  The behavior is very
unlikely used by anyone.

* Clang code generator treats STV_PROTECTED the same way as STV_HIDDEN:
  no GOT-generating relocation in the first place.
* gold and lld reject copy relocation on a STV_PROTECTED symbol.
* Nowadays -fpie/-fpic modes are popular.  GCC/Clang's codegen uses
  GOT-generating relocation when accessing an default visibility
  external symbol which avoids copy relocation.

Reviewed-by: Szabolcs Nagy <szabolcs.nagy@arm.com>