Allow for context-specific parameters in expressions

[anandthakker]

At the moment, we're only using expressions as data-driven style property values and (soon) filters. Those are both contexts in which zoom and feature data (properties/id/geometry type) are the only parameters to an expression, but we also want to use expressions in other contexts, too. For example,

• Property aggregation for clustered features Support property aggregation on clustered features #2412: this needs two expressions, map, which uses feature data, and reduce, which, in addition to feature data, also needs access to the current value of an accumulator.
• Heatmap layers Proposal: Heatmap layer type #4756 have a heatmap-color property which needs to define a color ramp -- i.e. a color-producing function that takes as input a number between 0 and 1 which is (i think?) essentially a relative density value. We could just specify this as a zoom-dependent expression, and then use evaluate({zoom: density}). However, that will surely be pretty confusing: ["curve", ["zoom"], 0, "red", 1, "blue"]. It would be clearer if users could write ["curve", ["heatmap-density"], 0, "red", 1, "blue"] instead.

Will the contexts in which we want to use these be few enough that we can just introduce specialized expressions (e.g. ["cluster-aggregated-properties"] for the former, ["heatmap-density"] for the latter), obviously only accepting them in the relevant contexts? Or do we need to generalize how we handle expression evaluation parameters? I lean towards the former.

@mapbox/gl-core

[jfirebaugh]

I lean towards specialized expressions too.

[anandthakker]

Went with the specialized-expression route for heatmap-density -- see #5407