Updates the MongoDB connector for ndc-spec v0.2 ([changelog link](https://github.com/hasura/ndc-spec/blob/9ce5e92e71ec3481e9d74741bd53dcdda3b6e81f/specification/src/specification/changelog.md#020))

The connector processes requests in two phases:
1. `ndc-query-plan` converts to an internal set of request types. In that process it denormalizes the request, annotates it with types, and constructs join plans. 
2. `mongodb-agent-common` consumes those internal types to produce mongodb query plans

This commit requires updates to both phases, including changes to the internal request types.

A number of unit tests still need to be updated according to the new mechanisms for handling relationships - specifically the change from root column references to named scopes. But we have integration tests for relationships which are passing which seems to indicate that things are generally working.

Implements most of the functionality for the capability `query.aggregates.group_by`. There are still a couple of things to follow up on.

Counts are not implemented for group by queries yet. I'll follow up on those in [ENG-1568](https://linear.app/hasura/issue/ENG-1568/[mongodb]-implement-count-for-group-by). (Counts are implemented in #145 which can be merged after this PR is merged.)

There is a bug involving multiple references to the same relationship that should be resolved. I'll follow up in [ENG-1569](https://linear.app/hasura/issue/ENG-1569).

While working on this I removed the custom "count" aggregation - it is redundant, and I've been meaning to do that for a while. Users can use the standard count aggregations instead.

There is a change in here that explicitly converts aggregate result values for "average" and "sum" aggregations to the result types declared in the schema. This is necessary to avoid errors in response serialization for groups when aggregating over 128-bit decimal values. I applied the same type conversion for group and for root aggregates for consistency. This does mean there will be some loss of precision in those cases. But it also means we won't get back a JSON string in some cases, and a JSON number in others.

This completes the basic functionality for group-by started in #144  by implementing all forms of count aggregations.

…#146)

The logic for count aggregations for grouped data in #145 was an improvement over what was already in place for ungrouped data. Instead of leaving two separate code paths with different logic I unified logic for both to use the new logic from #145.

This allowed removing unnecessary uses of the `$facet` stage which forks the aggregation pipeline. Previously every aggregate used a separate facet. Now we only need facets for incompatibly-grouped data - one query that combines ungrouped aggregates with groups, or that combines either of those with field selection. This required additional changes to response processing to remove facet unpacking logic. The new system does mean that there are a couple of places where we have to explicitly fill in null or zero results for aggregate queries with no matching rows.

While I was going over aggregate logic I noticed some unescaped field references when referencing aggregate result names. I fixed these to use `ColumnRef` which escapes names. While I was at it I removed the last couple of uses of the old `getField` helper, and replaced them with the new-and-improved `ColumnRef`.