Don't read variables for shadow sizes

[adamwathan]

Resolves #13438

In #13177 we changed the way utility values are referenced in utility classes to use variables with fallbacks instead of raw values:

  .pt-4 {
-   padding-top: 1rem;
+   padding-top: var(--spacing-4, 1rem);
  }

This creates an issue with colored shadows, because colored shadows rely on being able to override the value of a sub-variable that is reference by the actual shadow variable created based on your theme configuration.

Simplified but representative code:

:root {
  --shadow-sm: 0 1px 2px 0 var(--tw-shadow-color, black);
}

.shadow-sm {
  box-shadow: var(--shadow-sm, 0 1px 2px 0 var(--tw-shadow-color, black));
}

.shadow-blue {
  --tw-shadow-color: blue;
}

The problem here is that var(--shadow-sm, ...) will see that --shadow-sm is defined on :root, and use the computed value of that variable from :root, where --tw-shadow-color is yet to be defined, so the color falls back to black even when using the shadow-blue utility:

<!-- Shadow is still black, not blue like you might expect -->
<div class="shadow-sm shadow-blue">
  <!-- ... -->
</div>

This caught me by surprise personally as I expected CSS variables to be evaluated lazily but it seems like they are not. The only solution I've found here is to not reference the --shadow-sm variable in the .shadow-sm class, to make sure the value of --tw-shadow-color on the current element is respected, rather than looking for the value of --tw-shadow-color where --shadow-sm is defined:

  :root {
    --shadow-sm: 0 1px 2px 0 var(--tw-shadow-color, black);
  }
  
  .shadow-sm {
-   box-shadow: var(--shadow-sm, 0 1px 2px 0 var(--tw-shadow-color, black));
+   box-shadow: 0 1px 2px 0 var(--tw-shadow-color, black);
  }
  
  .shadow-blue {
    --tw-shadow-color: blue;
  }

This is pretty unfortunate because now our box shadow utilities behave subtly differently than every other utility in the framework. I'm hoping we can find some trick to make these variables lazily evaluated, and tweeted about it in case someone else out there has any ideas.

For now though we should merge this to effectively selectively revert #13177 for the affected utilities.