refactor(styles): centralize derived color tokens in variables.scss for less opinionated overrides

[Jollus174]

Description

Linked issue: N/A (theming / DX improvement; no existing issue)

Problem

Datepicker colors were partly defined in variables.scss and partly computed inline in datepicker.scss via color.adjust() and rgba(). That made Sass theming harder: consumers overriding base tokens could not easily override derived states (hovers, disabled selection, chevrons, keyboard-selected), and the var(--…) compile-time limitation was undocumented.

The issue I had was that I'd like to be able to consistently assign --css-variables to the $sass_variables. This is because in our sites, theming colours come from the CMS and are set as CSS variables. This doesn't work with React Datepicker, as the SASS variables are essentially built-time and are adjusted through the whole project, and aren't all in a centralised place. Ideally, they should all be in variables.scss, so I've moved them. 😊

I'd also say that the existing styling implementation could be considered being rewritten with CSS variables rather than SASS variables, including lighten / darken / rgba adjustments, which can be accomplished in CSS with color-mix() and relative colour syntax). That could be a PR for another time. For now, it's just centralising the SASS colours, which I think would benefit everyone and not cause any breakage.

Changes

Centralized all Sass color transforms in variables.scss as named $datepicker__* variables with !default, including:

• $datepicker__selected-color--disabled, --hover, --keyboard-selected-bg
• $datepicker__highlighted-color--hover, $datepicker__holidays-color--hover
• $datepicker__muted-color--chevron-dim, --navigation-hover-border
• $datepicker__navigation-disabled-color (unchanged formula, now grouped with other derived tokens)
  Updated datepicker.scss to use those variables only (removed inline color.adjust and @use "sass:color").
  Added a Sass / stylesheet theming section to CONTRIBUTING.md covering !default, override order, and the requirement to override derived tokens when bases are set to var(--…).
  Default compiled colors are unchanged for consumers who do not customize Sass variables.

Screenshots

N/A — no visual change with default palette. Theming is a Sass/API change only.

To reviewers

Think you could sanity-check hover/disabled/chevron colors in the docs site if you want extra confidence; I verified yarn sass-lint, yarn run css:dev, and yarn run css:modules:dev.
mixins.scss was already using module variables; no logic change there.
Happy to promote hardcoded literals (#fff, #333, etc.) to optional tokens in a follow-up if desired.