feat(cards): support lowercase and capitalized JSON values for Spacing

[cnaples79]

Summary

This PR updates the Spacing type and the JSON schema to support both lowercase and capitalized values for the spacing property in Adaptive Cards. This addresses the inconsistency between the Adaptive Cards Designer, which uses capitalized values, and the linter in this repository, which prefers lowercase values.

Changes

• packages/cards/src/core.ts: Added lowercase and camelCase variants to the Spacing type definition.
• packages/cards/schema.json: Updated the regex for 13.columnSpacing to include ExtraSmall and its variants.

Rationale

This change avoids confusion for developers and improves the developer experience by allowing either casing to be used for the spacing property. Both capitalized and lowercase values are rendered correctly in Teams, so this change makes the SDK more flexible.

Fixes #132

[corinagum]

@cnaples79 thanks for the contribution! Unfortunately this method won't work, since schema.json and core.ts are generated files and would be overwritten next time the schema is updated. I think it would be best to come up with a proposal to handle these programmatically.

IIRC schema.json is not used directly, so core.ts would need to be updated. @aacebo could you verify?

[cnaples79]

@corinagum I see, got it thanks for the feedback. I'll work on updating the implementation.

[dclaux]

@cnaples79 all enum values are case insensitive in Adaptive Cards, thus the use of those ugly regular expression patterns in the schema.

The designer uses the schema to support showing errors in the payload. But is uses a version of the schema where enum values are NOT defined as patterns. The reason for that is if it did use patterns, you wouldn't get squiggles for say the "extraLarge" value spelled with a lowercase "e" at the beginning., but if somehow you misspelled it as "extraLqrze" (misspelling happens all the time) the error message you'd get in the JSON editor would mention the regular expression which is undecipherable for any normal human.

So, the design decision in the designer was to favor having human-friendly error messages in the designer, even if that means enum values often get squiggles despite being valid.

Changing the spelling of the Spacing enum values would not fix the problem, it would just move it (instead of getting a squiggle for "extraLarge", you'd get one for "ExtraLarge" which is still perfectly valid.)

Bottom line, I do not think this change makes sense.

Note all of this is entirely due to JSON Schema's lack of proper support for case-insensitive enum values.