feat(theming): add system opacity values to the theme

[jzempel]

Description

This PR introduces a consistent set of themed opacity values and updates getColor to receive either one of the theme's 100-1200 keys or a value between 0 and 1. Garden will strive to use theme.opacity keys for all v9 opacity/transparency applications.

Detail

I weighed adding opacity under the colors theme structure, but stuck with root placement since CSS opacity applies to more than just color.

Checklist

• 👌 design updates will be Garden Designer approved (add the designer as a reviewer)
• 🌐 demo is up-to-date (npm start)
• ⬅️ renders as expected with reversed (RTL) direction
• 🤘 renders as expected with Bedrock CSS (?bedrock)
• 💂‍♂️ includes new unit tests. Maintain existing coverage (always >= 96%)
• ♿ tested for WCAG 2.1 AA accessibility compliance
• 📝 tested in Chrome, Firefox, Safari, and Edge

[coveralls]

coverage: 96.216% (-0.004%) from 96.22%
when pulling 700f17b on jzempel/theming-opacity
into 55eefa6 on next.

[geotrev]

I was thinking about fallback values when theme.opacity may contain invalid entries, but it may be too heavy handed to force consumers down an unexpected path vs letting getColor provide users with an error.

[geotrev]

🎉

[jzempel]

I was thinking about fallback values when theme.opacity may contain invalid entries, but it may be too heavy handed to force consumers down an unexpected path vs letting getColor provide users with an error.

Ah, that reminds me, I wanted to handle invalid opacity references before the rgba function throws a PolishedError. Added now. Later, if we find the need to accept intermediate key values, we'll add an adjust like we currently do with shade. But the current design intent is to stick with these canonical values.