Write application tokens ADR

We should cover naming and lifecycle like https://github.com/openedx/frontend-plugin-framework/blob/master/docs/decisions/0003-slot-naming-and-life-cycle.rst does

We should also make it clear what application tokens are part of the API contract. https://github.com/openedx/frontend-app-authoring/pull/2837/ added a bunch of CSS vars purely from a DRY/avoiding hardcoded color hex values perspective. Brand packages can modify those now, but that doesn't mean we want to commit to supporting those CSS vars. We shouldn't prevent application developers from using CSS vars for cleaner style architecture out of fear that theme authors will rely on those and they'll become part of an API contract we need to support.

Another little thing to decide is how to handle fallbacks in var( vs having application stylesheets define values for vars on :root. In frontend-app-catalog we use the fallback method for the banner background color, and there's no downside there because it's consumed in one place. In the authoring PR example using fallbacks would defeat the purpose of using CSS vars to keep it DRY. I'm ok with having this be a judgement call thing, but if we want to standardize that's worth considering too.

Start by reading the linked slot-naming and life-cycle ADR, then compare the fallback usage in frontend-app-catalog with the CSS variables added in frontend-app-authoring PR #2837. The ADR should document application-token naming and lifecycle, distinguish API-contract tokens from internal CSS variables, and explain how fallback decisions are handled.