[send-non-sendable] Recurse to the full underlying value computation instead of just the object one when computing the underlying object of an address.

[gottesmm]

Otherwise, depending on the exact value that we perform the underlying look up at... we will get different underlying values. To see this consider the following SIL:

  %1 = alloc_stack $MyEnum<T>
  copy_addr %0 to [init] %1
  %2 = unchecked_take_enum_data_addr %1, #MyEnum.some!enumelt
  %3 = load [take] %2
  %4 = project_box %3, 0
  %5 = load_borrow %4
  %6 = copy_value %5

If one were to perform an underlying object query on %4 or %3, one would get back an underlying object of %1. In contrast, if one performed the same operation on %5, then one would get back %3. The reason why this happens is that we first see we have an object but that it is from a load_borrow so we need to look through the load_borrow and perform the address underlying value computation. When we do that, we find project_box to be the value. project_box is special since it is the only address base we ever look through since from an underlying object perspective, we want to consider the box to be the underlying object rather than the projection. So thus we see that the result of the underlying address computation is that the underlying address is from a load [take]. Since we then pass in load [take] recursively into the underlying value object computation, we just return load [take]. In contrast, the correct behavior is to do the more general recurse that recognizes that we have a load [take] and that we need to look through it and perform the address computation.

rdar://151598281

[gottesmm]

@swift-ci smoke test

[rjmccall]

This seems consistent given what I understand of the current rules.