Itype support for global variables and struct fields: limit wildness propagation + handle existing itypes sensibly

[mattmccutchen-cci]

Currently, 3C's "liberal itypes" feature limits the spread of wildness through function calls, but 3C has no analogous feature to limit the spread of wildness through global variables and struct fields. It should. Most likely, this would just be an extension of liberal itypes, but we would probably need to implement "symmetric" liberal itypes (#743) first. Conceivably, we might take a different approach for global variables and struct fields.

Here's a simple example program for wildness propagation:

int *g;

void foo(int *x) {
  int *x1 = x;
  g = x1;
}

void bar(void) {
  g = (int *)1;
}

In current 3C, the assignment in bar forces both g and x1 to remain wild, so the only change 3C makes is to put a liberal itype on x. With liberal itypes for globals, we might expect to get something like the following where x1 has become checked, assuming we're sufficiently confident that the checked pointer type of g is in fact supposed to be _Ptr:

int *g : itype(_Ptr<int>);

void foo(_Ptr<int> x) {
  _Ptr<int> x1 = x;
  g = x1;
}

void bar(void) {
  g = (int *)1;
}

Also, regardless of any "liberal itypes" design for global variables and struct fields, we should ensure 3C behaves sensibly when it encounters a global variable or struct field with an existing itype. Currently, 3C treats the element as if its type were simply the right side of the itype, which can lead to the itype being unexpectedly lost if 3C rewrites the type of the element.