Flatten nested imports and add deprecation notice

[joshblack]

Discussion: #8642

This issue is for tackling the normalization of our export strategy. Currently, we export a mixed of named exports and exports only available as fields on these exports. For example: TextInput and TextInput.ControlledPasswordInput.

With this change, we would like all exports to be available as named exports. To get there, we will need to:

• Identify all components that are exported as a field on another component
• Determine their export name in the normalized approach
• Add each component as an export using the normalized approach
• Add a deprecation notice to the old import with a message instructing teams on how to migrate to the new import

[joshblack]

For deprecation notices, we may need to do something like:

function deprecateOnField(object, field, Component) {
  Object.defineProperty(object, field, {
    enumerable: true,
    get() {
      // Add deprecation notice here
      return Component;
    },
  });
}

// ...

deprecateOnField(TextInput, 'ControlledPasswordInput', ControlledPasswordInput);

[tay1orjones]

I think these are the only components exported as a field on another component:

• TextInput.ControlledPasswordInput
• TextInput.PasswordInput
• MultiSelect.Filterable
• ErrorBoundaryContext.Consumer - I don't think this one we really have control over or would want to change
• ErrorBoundaryContext.Provider - Same here

With proposed export name in the normalized approach

Current	Proposed
TextInput.ControlledPasswordInput	ControlledPasswordInput
TextInput.PasswordInput	PasswordInput
MultiSelect.Filterable	FilterableMultiSelect
ErrorBoundaryContext.Consumer	no change
ErrorBoundaryContext.Provider	no change

[joshblack]

@tay1orjones I think that tracks!

For the ErrorBoundary stuff, I think you're right. That should stay as consumer/provider