`match` expression shorthand for "true/false" evaluation?

Nobody has claimed this yet.

## Motivation

`match` expressions in filters need to explicitly output true/false assignments:

`[ "match", [ "get", "class" ], [ "path", "pedestrian" ], true, false ]`

Whereas comparison expressions directly evaluate to true/false:

`[ "==", [ "get", "class" ], "path" ]`

Even though this `match` pattern makes sense given how the syntax for this operator works, it still seems quite unintuitive/clunky in filters. I'm used to seeing data querying syntax and data filtering UI in other languages/programs treat "is true, otherwise false" as implied.

## Design Alternatives

The current design does not block any filtering abilities, so I think it would be ok if we left it as is. I'm also not sure if this is something that Studio would abstract out (cc @tristen @samanpwbb)

## Design

I have no idea how practical/feasible this is, but could we allow `match` expressions to only have three arguments (operator, input, label_1), and default these expressions to have output_1: `true`, default: `false`? I think this would basically mimic the `in` operator functionality in our deprecated filter syntax.

This seems mainly useful for filters, but perhaps it would be helpful for boolean style properties as well.

Perhaps `case` expressions could have the same shorthand (I haven't thought about this much because I haven't used this operator much in filters).

### Mock-Up

This would be valid:

`"filter": [ "match", [ "get", "class" ], [ "path", "pedestrian" ] ]`

### Concepts

I think we have precedent for this type of shorthand with `get` and `has` expressions (where the last argument is optional, and defaults to the current feature's properties).

### Implementation

I'm not sure what implications this may have for Studio or other parts of the Mapbox ecosystem.

/cc @anandthakker @jfirebaugh @mapbox/maps-design

The issue proposes shorthand forms for match expressions in filters and possibly case expressions, but names no files or tests. Start by locating the expression implementation and related filter tests, then assess compatibility with existing syntax and Studio or other Mapbox consumers. Done means a feasible, agreed design and corresponding implementation and test coverage.

Written by the indexing model from the issue text.