fix: display clean string literal values without quotes in docs

[Who-is-PS]

Issue #, if available:
AWSUI-61340

Description of changes:

Fixed an issue where CodeEditorProps.Language type values were incorrectly formatted in generated component definitions. The LiteralUnion<BuiltInLanguage, string> type was not properly recognized as a primitive string type, causing language values to appear as "\"javascript\"" instead of "javascript" in the documentation.

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 96.77%. Comparing base (3df5b77) to head (afa61e9).

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #101      +/-   ##
==========================================
+ Coverage   96.68%   96.77%   +0.09%     
==========================================
  Files          11       11              
  Lines         845      869      +24     
  Branches      284      297      +13     
==========================================
+ Hits          817      841      +24     
  Misses         28       28              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[Who-is-PS]

Expected test is failing. Will follow our SOP once it is released.

[gethinwebster]

I don't think that this is a valid representation of the type. For example, if we follow this through to the website, it would suggest that there would be an item "string" in the language selector dropdown, but that is not valid, as it's not a literal value, it's a type. We need to retain that differentiation between literal values and types in the documenter output.

The more that I think about this problem, the more that I think the problem is maybe not actually in the documenter but in the website: the documenter is currently generating output that accurately represents the underlying typings, the website just needs some extra logic to be able to handle some of the edge-cases better