GlimmerWrapper: Resolve modules without a default export

[mixonic]

Currently the implementation of RequireJSRegistry only finds default exports.

We would like it to honor named exports. There are two cases where this matters.

Case 1: named exports. For example:

// src/ui/components/my-foo.js
import Ember from 'ember';

export const helper = Ember.Helper.helper(() => {
  // some helper logic
});

We expect the absolute module identifier of ui/components/my-foo/helper would resolve this helper.

Case 2: default exports without type in the name. For example:

// src/ui/components/my-foo.js
import Ember from 'ember';

export default Ember.Component();

We expect the absolute module identifier of ui/components/my-foo/component would resolve this helper.

[mixonic]

Another way to put this is that the following lookup would occur for a specifier:

helper:/my-app/components/my-foo

my-app/src/ui/components/my-foo/helper w/ default
my-app/src/ui/components/my-foo w/ named helper

component:/my-app/components/my-foo

my-app/src/ui/components/my-foo/component w/ default
my-app/src/ui/components/my-foo w/ named component
my-app/src/ui/components/my-foo w/ default b/c defaultType

I don't actually this functionality is hard required to consider module unification support basically complete. Going to close this for now but I've bounced it off @rwjblue and @dgeb for feedback.

Closing for now.

[mixonic]

Talked about this with @iezer. Case 2 above is used by the migrator, and we should support it. This can be done by considering the defaultType of a collection and trying to resolve without /type at the end of the requirejs module if the defaultType of the current collection is being resolved.

@iezer has a stab at this in the first commit of #183, but it doesn't consider defaultType.