Ensure all custom property usage has fallbacks

[sgomes]

In general, we should strive to use the following pattern as much as possible, when using custom property values in CSS:

.foo {
  /* For browsers that don't understand custom properties */
  color: black;
  /* `black` used as fallback if `--color` isn't defined */
  color: var(--color, black);
}

Acceptable alternatives include wrapping custom property usage inside @supports blocks:

@supports(--css-vars: 'yes') {
  /* ... */
}

or otherwise making sure (through JS, for example), that the browser supports custom properties before using them.

That said, it can generally be considered a code smell to have a var() lookup without a second parameter (the fallback).

Tasks:

• Ensure all var() lookups have a second parameter
• Ensure all var() lookups have a fallback of some sort for browsers that don't support custom properties
• Run material-components-web generated CSS through postcss-custom-properties. Remove any errors and attempt to reduce warnings as much as possible, while taking into account the limitations of the tool.

This is a follow-up to #360.

[traviskaufman]

👍 👍 👍

Perhaps we could write / contribute to a stylelint rule which enforces that all custom props have a fallback?

[sgomes]

Done in #367.