Stylelint: enable no-token-fallback-values (almost) everywhere

[simison]

Follow-up to linter config started at:

• Stylelint: lint wordpress/theme design token usage #50110
• Stylelint: no WPDS token fallback values for WP Build routes #50502

...and numerous PRs meanwhile to add fallback token handling and linting to big chunk of the repo.

Among files with --wpds-* the linter + build time fallbacks now cover:

	Covered	Total	%
Files	147	173	85.0%
Packages	16	21	76.2%

Not on the rule: charts, components, base-styles, social-previews, plugins/jetpack

Those others are pretty complicated:

• use LightningCSS, not PostCSS:
  • charts (Charts: inject wpds fallbacks during build #50614)
  • social-previews (Social previews: add WPDS token fallbacks at build time #50646)
• Jetpack plugin still relies on old Calypso colour schemes a little too much
• components and base-styles are just unique cases otherwise

Proposed changes

• Enable no-token-fallback-values by default, except on folders still not going through build pipeline that adds the tokens at build-time.

Related product discussion/links

Does this pull request change what data or activity we track or use?

Testing instructions

• Lint is passing.

[github-actions]

Thank you for your PR!

When contributing to Jetpack, we have a few suggestions that can help us test and review your patch:

• ✅ Include a description of your PR changes.
  
• ✅ Add a "[Status]" label (In Progress, Needs Review, ...).
  
• ✅ Add testing instructions.
  
• ✅ Specify whether this PR includes any changes to data or privacy.
  
• ✅ Add changelog entries to affected projects
  

This comment will be updated as you work on your PR and make changes. If you think that some of those checks are not needed for your PR, please explain why you think so. Thanks for cooperation 🤖

---

Follow this PR Review Process:

1. Ensure all required checks appearing at the bottom of this PR are passing.
2. Make sure to test your changes on all platforms that it applies to. You're responsible for the quality of the code you ship.
3. You can use GitHub's Reviewers functionality to request a review.
4. When it's reviewed and merged, you will be pinged in Slack to deploy the changes to WordPress.com simple once the build is done.

If you have questions about anything, reach out in #jetpack-developers for guidance!