…ssues with nested fields (#1361)

### What
This PR reworks the GraphQL schema annotation types and IR parsing for
boolean expressions. This was required because the existing code was
quite tangled and broken as it did not properly handled nested fields.
For example, it had the following issues:

* If you use more than one nested field in a single where, an invalid
NDC query is generated with mangled field paths
* If you use logical operators inside a nested field, an internal error
occurs

The new annotation structure and IR parsing code cleanly matches the two
types of boolean expressions we currently have: object boolean
expressions and scalar boolean expressions. The new parsing code
correctly tracks nested fields and allows arbitrary nesting of object
boolean expressions (and therefore logical operators at the object
boolean expression level).

### How

In `crates/graphql/schema/src/types.rs` `BooleanExpressionAnnotation`
has been reworked to capture the two different types of boolean
expressions. It now has the two `ObjectBooleanExpressionField` and
`ScalarBooleanExpressionField` variants, which are used to denote fields
on each of the different types of boolean expression objects. Previously
scalar boolean expression annotations lived on `ModelInputAnnotation`,
muddying the waters.

Then in `crates/graphql/ir/src/filter.rs`, we have
`resolve_object_boolean_expression` and
`resolve_scalar_boolean_expression` which are capable of reading the
respective variants of boolean expressions.
`resolve_object_boolean_expression` is recursive, and so nested logical
operators are handled naturally. As nested fields are descended through,
this is kept track of with `column_path`.

Some new fields were added to the existing nested object test
(`crates/engine/tests/execute/models/select_many/where/nested_select/object/request.gql`)
to capture and test the previously broken scenarios.

A minor fix was made to `crates/graphql/frontend/src/to_opendd_ir.rs`
because it did not handle multiple root fields properly, as it did not
use the root field aliases and ended up overwriting the same query over
and over. This resulted in many snapshots getting updated, even though
they are unrelated to the real change in this PR.

V3_GIT_ORIGIN_REV_ID: f7cbbe8c86f542150e0ce247c6597df717836c06