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

We have had users unable to run introspection because sampling fails on an automatically-generated collection called `system.views`. This collection is generated if the database has any views. On some deployments attempts to run aggregate (which is what introspection sampling uses) fail with a permissions error. We've seen this come up in MongoDB v6 running on Atlas.

Collections prefixed with `system.` are reserved for internal use. We shouldn't include them in introspection. https://www.mongodb.com/docs/manual/reference/system-collections/#synopsis

This PR makes two changes:
- skip collections whose names begin with `system.`, and log a warning
- when sampling a collection fails for any reason skip that collection and log a warning instead of failing the entire introspection process

When sending response data for a query if we encounter a value that does not match the type declared in the connector schema the default behavior is to respond with an error. That prevents the user from getting any data. This change adds an option to silently skip rows that contain type mismatches so that the user can get a partial set of result data.

This resolves a problem connecting to the open telemetry trace collector.

Fixes https://linear.app/hasura/issue/ENG-1775/mongodb-certificate-error-connecting-to-otel-collector

Bump to new SDK so we output connector name and version in traces.