gdb: prefer lhs type's address spaces/classes in check_typedef

gdb: prefer lhs type's address spaces/classes in check_typedef

In commit 92fdad7 "gdb: convert type instance flags to bitfields",
`operator|=` of type_instance_flags required the address space and
address class values of left-hand-side to be zero.  This introduced
the following bug (thanks to Keith Seitz for reporting it at
https://inbox.sourceware.org/gdb-patches/053e90c0-53f0-4748-9d27-0237b9f21221@redhat.com/T/#u):

  typedef int myint;

  (gdb) ptype (@code myint) 3
  ../../src/gdb/gdbtypes.h:127: internal-error: operator|=: Assertion
  `harvard_aspace == 0' failed.
  A problem internal to GDB has been detected,
  further debugging may prove unreliable.
  ----- Backtrace -----
  0x5bb1d1 gdb_internal_backtrace_1
          ../../src/gdb/bt-utils.c:122
  0x5bb210 _Z22gdb_internal_backtracev
          ../../src/gdb/bt-utils.c:173
  0xdfbbaa internal_vproblem
          ../../src/gdb/utils.c:434
  0xdfbf45 _Z15internal_verrorPKciS0_P13__va_list_tag
          ../../src/gdb/utils.c:514
  0x162763f _Z18internal_error_locPKciS0_z
          ../../src/gdbsupport/errors.cc:57
  0x87e8e6 _ZN19type_instance_flagsoRERKS_
          ../../src/gdb/gdbtypes.h:127
  0x875d71 _Z13check_typedefP4type
          ../../src/gdb/gdbtypes.c:3072

The |= operator is used in check_typedef as follows:

      /* Preserve the instance flags as we traverse down the typedef chain.

         Handling address spaces/classes is nasty, what do we do if there's a
         conflict?
         E.g., what if an outer typedef marks the type as class_1 and an inner
         typedef marks the type as class_2?
         This is the wrong place to do such error checking.  We leave it to
         the code that created the typedef in the first place to flag the
         error.  We just pick the outer address space (akin to letting the
         outer cast in a chain of casting win), instead of assuming
         "it can't happen".  */
      {
        type_instance_flags new_instance_flags = type->instance_flags ();

        /* Treat code vs data spaces and address classes separately.  */
        if (instance_flags.harvard_aspace != HARVARD_ASPACE_NONE)
          new_instance_flags.harvard_aspace = HARVARD_ASPACE_NONE;
        if (instance_flags.address_class != 0)
          new_instance_flags.address_class = 0;

        instance_flags |= new_instance_flags;
      }

So, the assertion in operator|= was wrong.  The outer type, which is
the left-hand-side in this case, should preserve its values if they
are non-zero.  The right-hand-side values are used, if lhs values are
zero.  Fix the bug accordingly.

Furthermore, rename operator|= to "merge".  Type instance flags are no
longer stored as a bitmask value, but rather as a struct.  Having an
operator like |= gives the wrong impression that we are doing a
bitmask OR.  Using a method makes the intention clearer.

Include a regression test.

Reviewed-By: Keith Seitz <keiths@redhat.com>
Approved-By: Tom Tromey <tom@tromey.com>