Uniformly export component "Base" implementations

[KevinTCoughlin]

Pull request checklist

• Addresses an existing issue: Fixes We do not uniformly export the "Base" version of components. #5772
• Include a change request file using $ npm run change

Description of changes

Tackled this as I'm waiting to go over the contextual menu changes with Micah. I audited the components and added all missing "Base" implementations I could find. There were also some .types exports missing that are probably necessary to theme the components successfully.

Remaining non-exported components that I was unsure about w.r.t API surface:

• CalloutContent.base
• ChoiceGroupOption & ChoiceGroupOption.base
• ColorRectangle & ColorSlider
• DetailsHeader.base
• GroupHeader.base / GroupFooter.base / GroupShowAll.base
• KeyTipContent.base
• MarqueeSelection et al are not exported

Some of the above should likely also be exported for customization to work as expected, but would like to double check.

Focus areas to test

Please ensure that the public API surface is as expected with these additional exports.

Microsoft Reviewers: Open in CodeFlow

[KevinTCoughlin]

Hmm prettier seems to have opinions about AppState when I committed after resolving conflicts 0_0

[JasonGore]

If you don't get a clean merge, prettier will run against all of the files that were merged in from master. :/ I usually get around it by reverting conflict files to allow an automerge then reapply. (We still need to figure out how so many files are changing on master without prettier running against them.)

I'm a bit concerned about exporting base implementations because I consider them somewhat of an component implementation detail. This will become more of an issue with createComponent. How exactly will they be used? I'm wondering if it would be better to require direct importing to not make it part of the default API surface.

[cliffkoh]

The base components are viewed as the pure unstyled components, and the idea was always to allow styled variants to be created around these bases using styled. We are not fulfilling this promise ATM. Additionally, there is no way to completely opt out of Fabric styles if you want to have your own custom theme without the base component.

You could technically attempt to overwrite everything but think for a moment how unfeasible that is in reality :)

[JasonGore]

This will get a bit more complicated if we roll out createComponent as there is no "base" component... although I guess we could create an equivalent without styling.

[cliffkoh]

@KevinTCoughlin you need a change file.

[KevinTCoughlin]

@cliffkoh yea wasn't sure on where you both landed re: this change so didn't want to include a change to have it merged. Is this still worth doing with the createComponent work? We could keep it so they need to directly import the class, but it seemed worth doing to me giving the mergeStyles work for those that really expect the flexibility for a number of components. Also for consistency but that's less of a good reason.

If we're OK with this I'm assuming minor bump?

[KevinTCoughlin]

@cliffkoh + changefile w/ minor bump