[WNMGDS-3350] Remove form components table

[jack-ryan-nava-pbc]

Summary

• Ticket
• We attempt to render an additional styling table for form components, however there is no component named "form" in the Tokens lists (or in the design system, it is a pattern) so we are unable to render any additional form styling tables.
• This ticket removes all mentions of <ComponentThemeOptions componentname="form" /> in our MDX files, and the associated text providing context for those tables.
• I also took the liberty to add a little message for when no additional styling variables exist for a given component.

How to test

1. Search for <ComponentThemeOptions componentname="form" /> in the codebase. There should be 0 results.
2. Fire up the doc site locally, and add <ComponentThemeOptions componentname="form" /> to a random MDX page. You should see the message No variables available for component: "form". Happy to discuss whether this is needed or not.

Checklist

• Prefixed the PR title with the Jira ticket number as [WNMGDS-####] Title or [NO-TICKET] if this is unticketed work.
• Selected appropriate Type (only one) label for this PR, if it is a breaking change, label should only be Type: Breaking
• Selected appropriate Impacts, multiple can be selected.
• Selected appropriate release milestone

[tamara-corbalt]

Looks great! Just one non-blocking question

[tamara-corbalt]

This logic makes sense to me, although I'm not sure how much value the fallback message adds for the end user. Would it make more sense to return null early if componentVariables.length === 0 to avoid rendering anything at all?

[jack-ryan-nava-pbc]

I was between that option and the above code. I think my intent here is to signal something to us devs that this isn't working as expected, and that's because the ComponentThemeOption component is often rendered below another heading that provides context, and if this is the only thing there, then it makes sense to alert the devs and have them remove the whole section.

But maybe I'm over thinking it and should make it simpler?

[tamara-corbalt]

I hear you—that makes sense. I don’t have strong feelings about this, so feel free to disregard, but I wonder if there’s a way to split the difference? Maybe return early if it's empty, but issue a console.warn in development?

[jack-ryan-nava-pbc]

Ok, yeah that is the pattern we use for downstream packages. I guess it doesn't make sense to do it a different way for ourselves, but I'm just trying to make sure we don't miss anything, and burying it in the console feels like a way to miss it... I'll go with your suggestion for consistency and maybe I'm over thinking it. Thanks @tamara-corbalt !

[kim-cmsds]

@jack-ryan-nava-pbc can you please add a check for whether the environment is production? I don't think we should be adding a console warning in that case.