feat(DesignTokens): nest default and dark colors in same tokens files

What does this MR do?

Why

1. Compute modes when importing tokens into Figma see: !4143 (closed) (other implementation using .dark.tokens.json file extension !4093 (closed)
2. Reduce duplication of token names and other properties like "$type": "color" etc.
3. Reduce number of tokens.json files in /src/tokens/ directory

Changes

• Add default and dark properties to $value property in color design tokens with dark mode variants
• Remove .dark.tokens.json files

Testing locally

To validated generated CSS/SCSS/JSON/JS output from style-dictionary (ignore timestamps in diffs):

git checkout main
rm -rf ./dist/tokens && yarn build-tokens
git add --force ./dist/tokens
git checkout design-tokens-value-object
rm -rf ./dist/tokens && yarn build-tokens
git diff ./dist/tokens

Notable changes:

1. All SCSS variables have !default regardless of mode
2. Some order of output will change in tokens.grouped.json
   1. This isn't being used by anything and should be removed to simplify build_tokens.js
   2. This is internal logic within style-dictionary to ensure aliased tokens are defined before being used
3. Brand colors and line-height values removed from dist/tokens/json/tokens.dark.json output, which is as expected as these do not have dark mode values defined
4. dist/tokens/json/tokens.json output updates isSource to true as the token is from a file defined in the source array as opposed to include in the configuration https://amzn.github.io/style-dictionary/#/tokens?id=default-design-token-metadata

Screenshots or screen recordings

Before	After
master.zip	branch.zip

Integration merge requests

• GitLab: gitlab!151721 (closed)
• CustomersDot: mr_url
• Status Page: mr_url

Does this MR meet the acceptance criteria?

This checklist encourages the authors, reviewers, and maintainers of merge requests (MRs) to confirm changes were analyzed for conformity with the project's guidelines, security and accessibility.

Toggle the acceptance checklist

Conformity

• Code review guidelines.
• GitLab UI's contributing guidelines.
• If it changes a Pajamas-compliant component's look & feel, the MR has been reviewed by a UX designer.
• If it changes GitLab UI's documentation guidelines, the MR has been reviewed by a Technical Writer.
• If the MR changes a component's API, integration MR(s) have been opened (see integration merge requests above).
• Added the ~"component:*" label(s) if applicable.

Security

If this MR contains changes to processing or storing of credentials or tokens, authorization and authentication methods and other items described in the security review guidelines:

• Label as security and @ mention @gitlab-com/gl-security/appsec
• Security reports checked/validated by a reviewer from the AppSec team

Accessibility

If this MR adds or modifies a component, take a few moments to review the following:

• All actions and functionality can be done with a keyboard.
• Links, buttons, and controls have a visible focus state.
• All content is presented in text or with a text equivalent. For example, alt text for SVG, or aria-label for icons that have meaning or perform actions.
• Changes in a component’s state are announced by a screen reader. For example, changing aria-expanded="false" to aria-expanded="true" when an accordion is expanded.
• Color combinations have sufficient contrast.