DSLX: Confusing situation on aliased imports

[RobSpringer]

Internally, when we import a DSLX file, we allow an optional prefix on our import paths; IOW, import foo.bar is mostly the same as import baz.foo.bar. I'm not sure why we do this (maybe we probably shouldn't?), but if one mixes these formats, we get a very confusing error where it appears that a type is not equal to itself:

0017:     let ctr_enc = aes::encrypt(                                                                                         
0018:         key, aes_common::KeyWidth::KEY_256,                                                                             
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^-------^ XlsTypeError: KeyWidth vs KeyWidth: Mismatch between parameter and argument t
ypes.

This can happen if you have something like below:
File A:

import baz.foo.bar

fn something(x: bar::MyEnum) ...

File B:

import foo.bar
import A

fn something_else() {
  A::something(bar::MyEnum);
}

The root cause is that the different import paths cause ImportData to treat them as separate entities and to typecheck, etc. them separately. When it's time to deduce the invocation of something, it fails because in EnumType::operator==(), the addresses of the underlying EnumDefs differ.

Not sure what the immediate fix is - symlinks are something that are allowed to exist, and we might want identical types to be assignable anyway, i.e., maybe for the following to be valid:

struct MyStruct {
  a: u32,
  b: u32
}

struct MyOtherStruct {
  a: u32, 
  b: u32
}

const MY_CONST_STRUCT: MyStruct = MyOtherStruct { a: u32:0, b: u32:0 };

Thinking is needed.

[erinzmoore]

Unassigning for now since this seems like we might need to discuss some options as a team.