BREAKING: Button - implement dark theme and match redlines

[bcalvery]

affects light and dark

Button

• Modified Teams Dark Theme Button styles to match redline.
• Updating Teams default theme to match redline spec.
• removed "type" prefix for button style variables

API Change

"type" prefix removed from buttonVariables:

Before

After

(For general reference, hover, pressed, keyboard focus states not shown)

[codecov]

Codecov Report

Merging #336 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #336   +/-   ##
=======================================
  Coverage   89.33%   89.33%           
=======================================
  Files          64       64           
  Lines        1256     1256           
  Branches      186      163   -23     
=======================================
  Hits         1122     1122           
  Misses        131      131           
  Partials        3        3

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 45a1c41...12fdff3. Read the comment docs.

[alinais]

Lovely to see this one being worked on.

[levithomason]

Please remove secondaryTinted button type and replace it with a customization example where the variables are used to create this custom usage. This way, the API is not required by all themes.

[kuzhelov]

do we really want to remove for all the Stardust clients? What is the point to have type being a string with secondary removed - it should be a boolean flag then. However, would disagree that we should remove secondary from the list of types provided.

[bcalvery]

What does "secondary" mean though, vs just a "default" button? Or conversely, if we have a "primary" and "secondary" button visual treatment, then the "neither primary nor secondary button" becomes a liability (in the context of Teams at least) because there is no such thing as a button that isn't primary or secondary... do we make "primary" and "secondary" non-optional for button? That seems onerous.

I agree that perhaps "primary" should be a Boolean rather than a string... This might also be useful in "groups" of buttons, to make some sort of rule that breaks if there is more than one primary...

[kuzhelov]

lets agree on whether secondary should be removed as type enum value for Button @levithomason