Unify interface aliasing

[kajacx]

Fixes #110

Quick summary:

"Named" interface exports have both original name and aliased name in exports, but "local"/"inline" interfaces have only aliased export in the exported JS object.

interface guest-exports {
  run: func()
}

world my-world {
  export guest-exports // "named" interface

  export inline-exports: interface { // "local"/"inline" interface
    add-three: func(num: s32) -> s32
  }
}

TS bindings are already "correct" (according to what should be exported):

export interface Root {
  'example:protocol/guest-exports': typeof ExportsExampleProtocolGuestExports,
  'inline-exports': typeof ExportsInlineExports, // was missing in actual JS code
  guestExports: typeof ExportsExampleProtocolGuestExports,
  inlineExports: typeof ExportsInlineExports,
}

But the JS code did not export the non-aliased local interface export.

[guybedford]

Note my feedback on this PR is as per tc39/proposal-source-phase-imports#49 (comment).

[guybedford]

I realise I gave the wrong link to my feedback, I meant to link to #110 (comment).

The point remains that we should not merge this as-is, since the model is correct, and it is in fact that TS case that is incorrect providing the kebab name.

[kajacx]

Ok, I almost forgot about this issue. The workaround is really easy, you can see it here, so it's not a big deal if the JS code stays as it is. But it's true that the TS types should reflect the JS code, I'll try to change the PR.

[kajacx]

Ok, this code seems to "fix" the discrepancy in the TS types, but the code is kind of bad. It "exploits" the fact that external interface names contain a ":" in their name in a really bad way.

The proper solution would have been to store the interface name in a struct that would properly contain fields for the interface name itself, as well as the path of where it comes from, and then decide based on that instead of looking at the complete string representation.

But that would would require a significant refactor of the code, which is out of scope of this PR.

I still think this is the wrong choice, and exporting the original name from JS as well would have been better, but it's your project, you decide in which direction you want to go.

[guybedford]

Thank you @kajacx for the update here, this would be great to land as soon as the tests are passing.

To reiterate the main argument with respect to naming it is that JavaScript exports use idiomatic camel casing not kebab casing. It's only interface names which exist as canonical kebab interface names on exports for this specific deduping case. Perhaps in future we will have better middle ground deduping like namespaced camel conversions that we use instead here.

[guybedford]

Closing as discussed in #110 (comment).