[region-isolation] Fix semantics around assigning into projections

[gottesmm]

This PR contains a few different changes:

1. I improved the logging so it is easier to read.
2. When classifying an instruction as an assign, if the result/operand of the instruction maps to the same element, then we do not emit an assign. There are certain instructions that /always/ do this so I refactored them to instead of using an assign (and never emit anything) to instead just assert that the input/output values are the same. This exposed a different issue where in certain cases if we diagnose an error (via a require) but can't find the transfer instruction we do not emit an error. This can be seen in the tuple tests that I had to disable. In a subsequent commit I am going to change the compiler to emit a "I don't understand error" in such a case and investigate why in the tuple case we can't identify the transfer instruction.
3. Instead of using AccessStorage::compute directly, I changed the way that we identified address roots to use our own AccessUseDefChainVisitor so that we can determine if we saw a projection on the way to a root (and thus must treat an assignment as a merge).
4. The actual interesting commit. If we assign into a field of a struct/tuple with multiple stored fields, we must merge instead of assign. I included the entire commit msg below.

---

[region-isolation] Assigns to var with structs/tuples with multiple fields should be merges for now.

The reason that this is being done is that since currently region based
isolation is not field sensitive, when we assign to the struct or tuple field of
the var, the new region relationship is set for the entire struct, not just a
specific field. This means that we effectively lose any region information from
the other fields. For example in the following at (1), given the current rules, we
lose that s.y was assigned to x:

struct S {
  var x: NonSendableKlass
  var y: NonSendableKlass
}

func foo() {
  var s = S()
  // Regions: [s]
  let x = NonSendableKlass()
  let y = NonSendableKlass()
  // Regions: [(s), (x), (y)]
  s.y = x
  // Regions: [(s, x), (y)]
  s.x = y                       (1)
  // Regions: [(x), (s, y)]
}

The best solution to this is to track such var like bindings in a field
sensitive manner where the regions of the aggregate are the union of the
individual fields. This would let us represent the regions of the above as
follows:

func foo() {
  var s = S()
  // Regions: [((s.x), (s.y))]
  let x = NonSendableKlass()
  let y = NonSendableKlass()
  // Regions: [((s.x), (s.y)), (x), (y)]
  s.y = x
  // Regions: [((s.x), (s.y, x)), (y)]
  s.x = y                       (1)
  // Regions: [((s.x, y), (s.y, x))]
}

We cannot do this today so to plug this hole, we instead treat these operations
as merges. This provides a conservative answer. Thus we would have:"

func foo() {
  var s = S()
  // Regions: [s]
  let x = NonSendableKlass()
  let y = NonSendableKlass()
  // Regions: [(s), (x), (y)]
  s.y = x
  // Regions: [(s, x), (y)]
  s.x = y                       (1)
  // Regions: [(s, x, y])
}

This is because we are treating the assignment into s.y and s.x as merges into
s, so we do not lose that y was assigned into s before we assigned y into
it. The unfortunate side-effect of this is that if a struct or tuple has
multiple fields, the merge makes it so that if we assign over the same field, we
do not lose the region of the old value:

func foo() {
  var s = S()
  // Regions: [s]
  let x = NonSendableKlass()
  let y = NonSendableKlass()
  // Regions: [(s), (x), (y)]
  s.y = x
  // Regions: [(s, x), (y)]
  s.y = y                    (1)
  // Regions: [(s, x, y])
}

If we were not to do this, then the s.y at (1) would result in s and x being in
different regions.

rdar://117273952

[gottesmm]

@swift-ci smoke test

[gottesmm]

Slava is going to do post-commit review.