[Tokens] Improve Multiple-based objects for tokenator values integration

[pylapp]

Context

Today, the Figma kit defined by the design team exposed plenty of tokens, and some of these tokens are quite particular.
Indeed, we may have tokens for which the values rely on the color scheme (dark or light modes) or the size class (compact or regular).
However, they are until now considered as one token, but quite dynamic with multiple values.
To prevent users to have to deal with lots of tokens declinations, we choose to define Multiple* objects so as to contain pair of values ; depending to the token it will contain values for compact and regular size classes or light and dark color schemes. Thus, we will be able through the themes to expose one object with the two values available, as a "multiple token"/. The Android team uses also the same logic.

However, the Figma tool is not able to manage such configurations (and also composite values), so the tokenator converting its JSON to Swift won't be able to build such Multiple* objects. So the solution we agreed with @julien-deramond is the following one:

Given a  Figma token name "foo" having two possible values depending to the size class
- the tokenator will generate *fooCompact* for compact size class
- the tokenator will generate *fooRegular* for regular size class

Given a Figma token name "bar" having two possible values depending to the color scheme
- the tokenator will generate *barLight* for light color scheme
- the tokenator will generate *barDark* for dark color scheme

Then the iOS team will manualy define the `Multiple*` objects in a seperated file, with these steps: 
- define a "foo" iOS token with *fooCompact* token as value for compact size class and "fooRegular" token as value for regular size class
- define a "bar" iOS token with *barLight* token as value for light color scheme and "barDark" token as value for dark color scheme

Thus, having Multiple* objects will help us to test the tokens (i.e. ensure values are the expected one depending to configuration, mainly for InverseTheme) and also provide one "fake" token with the two possibles values, through the theme.

Today we have tokens depending to size class:

• MultipleSpaceTokens
• MultipleSizeTokens
• MultipleFontLetterSpacingTokens
• MultipleFontSizeTokens
• MultipleFontLineHeightTokens
• MultipleTypographyTokens

We have also tokens depending to color schemes:

• MultipleColorTokens
• MultipleElevationTokens (because of box shadow)

Note this is the same logic for composite tokens where the notion of "composite" does not exist in Figma, but invented by the design team, so the ¨tokenator* cannot provide the Swift cod ebecause the JSON it processes doe snot contin such objects. Composites are defined manualy based on generated tokens.

Definition of Ready

• For @julien-deramond / tokenator team, notify the iOS team they are ready to generate tokens suffixed by light, dark, compact, regular

Definition of Done (iOS team only)

• Extract "multiple tokens" variables to dedicated files, just like for the composite tokens (e.g. OUDSTheme+ElevationMultipleSemanticTokens
• Update the values given to these tokens for light, dark, regular, compact cases to point to the tokenator generated values
• Update documentation (catalogs and comments, precise which files is generated by or not the tokenator, logic with Figma, etc)
• Update tests
• Update the wiki to talk about the Multiple objects
• In DocC documentation of protocols and enums of tokens, update main comments if needed to say wether or not the file is generated by the tokenator (i.e. TypographyCompositeSemanticTokens won't be uopdate by tokenator)

Following types must be updated:

• MultipleSpaceTokens
• MultipleSizeTokens
• MultipleFontLetterSpacingTokens
• MultipleFontSizeTokens
• MultipleFontLineHeightTokens
• MultipleTypographyTokens
• MultipleColorTokens
• MultipleElevationTokens

draft.zip