Fix prototype keys causing crash in color parsing and invalid colors in color coercion expressions

[cxcorp]

From #1025

This PR fixes two issues:

1. When parsing color strings (e.g. text-color: "red"), parse_css_color.ts attempted to look up named colors from an object literal by doing namedColors[input]. If the color string was "__proto__" or "toString" or some other key in the Object prototype, the value was truthy, and caused an unhandled error to be thrown because the value was destructured.
   

   maplibre-style-spec/src/expression/types/parse_css_color.ts

   Lines 40 to 44 in 91175b3

   	const namedColorsMatch = namedColors[input];
   	if (namedColorsMatch) {
   	const [r, g, b] = namedColorsMatch;
   	return [r / 255, g / 255, b / 255, 1];
   	}

2. When a Coercion expression was used to coerce an expression's string value to a color (e.g. to_color), it used EvaluationContext.parseColor() which checked if the string had already been parsed and cached. The cache lookup was done via this._parseColorCache[input], where input comes from the user controlled style. As a result, the input was never parsed as the value was truthy, and the value from the prototype was returned and became the expression's value.
   

   maplibre-style-spec/src/expression/evaluation_context.ts

   Line 16 in 91175b3

   _parseColorCache: {[_: string]: Color};

   
   

   maplibre-style-spec/src/expression/evaluation_context.ts

   Lines 48 to 53 in 91175b3

   	parseColor(input: string): Color {
   	let cached = this._parseColorCache[input];
   	if (!cached) {
   	cached = this._parseColorCache[input] = Color.parse(input);
   	}
   	return cached;

Fixing issue 1 revealed issue 2, as EvaluationContext.parseColor() used Color.parse() which used parseCssColor(). Color.parse() is also used in function expressions.

The fixes for the issues were:

1. For parseCssColor(), since we probably want the convenience of using an object literal to initialize it, I opted to use the previously introduced (Fix validate_object crashing when object prototype keys used in style's objects #1028) getOwn() utility to ensure that only the literal's keys are tested.
2. For EvaluationContext.parseColor(), the _parseColorCache was previously initialized to an empty object literal {}. Since there was no need for the ergonomics of using a literal, I replaced it with Object.create(null) which creates an object without a prototype (note: {} is syntactic sugar for Object.create(Object.prototype)).

The ideal solution for this would be to systematically use a Map if the key is user-controlled, but I did not find any uses of it from the codebase and assumed that the library targets ES5 compatibility.

Launch Checklist

• Confirm your changes do not include backports from Mapbox projects (unless with compliant license) - if you are not sure about this, please ask!
• Briefly describe the changes in this PR.
• Link to related issues.
• Include before/after visuals or gifs if this PR includes visual changes.
• Write tests for all new functionality.
• Document any changes to public APIs.
• Post benchmark scores.
• Add an entry to CHANGELOG.md under the ## main section.

[codecov-commenter]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 92.74%. Comparing base (91175b3) to head (89d3c87).

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #1036   +/-   ##
=======================================
  Coverage   92.74%   92.74%           
=======================================
  Files         108      108           
  Lines        4728     4730    +2     
  Branches     1347     1347           
=======================================
+ Hits         4385     4387    +2     
  Misses        343      343           

☔ 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.

[cxcorp]

I noticed that there were both *.output-api-supported.json and *.output.json files in the tests, but was unable to find references to output-api-supported or api-supported in the codebase, other than a changelog entry saying --mapbox-api-supported had been removed from gl-style-validation in 14.0.0. Are the .output-api-supported.json files still used, or subject for removal in a later PR?

[HarelM]

I can't find anything related to this in the history of the repo, I'm not sure they were ever used, and also from a very shallow test I made these looks duplicates of the output files, so I would recommend removing them.

[cxcorp]

Sure. Remove in this PR or shall I make a separate PR?

[HarelM]

A separate PR seems like the right approach.