Handle invalid color scheme names

[colebemis]

Problem

If ThemeProvider is a passed an invalid color scheme name (e.g. <ThemeProvider dayScheme="foo">), it could potentially break an entire application. We noticed this happening in an internal React application.

Solution

This PR updates ThemeProvider to default to the first defined color scheme if it's passed an invalid color scheme name.

[changeset-bot]

🦋 Changeset detected

Latest commit: f0f8edc

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@primer/components	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[vercel]

This pull request is being automatically deployed with Vercel (learn more).
To see the status of your deployment, click below or on the icon next to each commit.

🔍 Inspect: https://vercel.com/primer/primer-components/HWjrVkvbSqeC5smKVHTpXSZam3xH
✅ Preview: https://primer-components-git-handle-unrecognized-color-schemes-primer.vercel.app

[smockle]

Non-blocking: I wonder if index 0 is magic-numbery? Though it may be our best option, since the Theme type definition doesn’t require a default/fallback scheme to be designated (example below). 🤔

export type Theme = {
  colorSchemes: {
    default: { [key: string]: any }
    [key: string]: any
  }
  [key: string]: any
}

[colebemis]

I agree that [0] feels a little bit wrong here. Unfortunetly, we can't make any assumptions about the format of the theme object without making a breaking change to the library. Let's move forward with this "incrementally correct" solution, and we can revisit TypeScript types for the theme object later.

[dgreif]

Great change. Definitely makes sense to have a fallback here