Add C++ query builder

[JasonAtClockwork]

Description of Changes

• Added a query builder for C++ module bindings
  • Added query-builder table/filter/join types
  • Added semijoin support with compile-time checks for lookup-table and indexed-field usage
  • Added support for returning query-builder queries from C++ views
  • Hooked query-builder metadata into the C++ table/view macros and V10 module-def path
• Added test coverage for the new C++ query-builder behavior
  • Compile tests for pass/fail cases
  • SQL tests for generated query output
  • Added a C++ test module for view primary key coverage
• Update: Switched the core to pass the columns and index-columns metadata with the table source for better client-side codegen to have some shared code between server + client.

API and ABI breaking changes

• No intended API or ABI breaking changes
• Adds a new public query-builder API to the C++ bindings
• C++ views can now return query-builder query types in addition to materialized row results

Expected complexity level and risk

3 - Mostly contained to C++ bindings, but it touches macros, view registration/serialization, and module-def generation, so there are a few places where the pieces need to stay in sync.

Testing

I've done end to end testing of I think every type as well as built some tests to confirm the SQL output.

• Run the C++ query-builder SQL tests [crates/bindings-cpp/tests/query-builder-compile/run_query_builder_compile_tests.sh]
• Smoke test a generated C++ module using query-builder views

[rekhoff]

Looks good to me. Some fairly minor nits here.

[JasonAtClockwork]

Updated the core query builder to carry generated column and index-column metadata alongside each table source. This was needed so downstream codegen can reason about the source shape directly instead of reconstructing it indirectly.

In practice, that lets the client generator produce source-aware query authoring APIs, expose the right fields and lookup surfaces, and support a much better Blueprint/C++ developer experience without maintaining a separate query-builder model.

[rekhoff]

Just a few items

[rekhoff]

Just one minor nit, otherwise looks good

[joshua-spacetime]

Why does the where predicate take both TCols and TIxCols? Index columns aren't relevant for where right?

[JasonAtClockwork]

Index columns aren’t required for where semantically. This split is there so chained queries don’t lose access to indexed-column predicates after earlier query steps. This isn't necessary for the pure C++ query builder, but I'm reusing this on the Unreal C++ side and want to keep them aligned which means a little extra API.

[joshua-spacetime]

Is there a way to keep the index cols internal and not part of the user facing api? To maintain consistency with the other query builders?

[JasonAtClockwork]

Is there a way to keep the index cols internal and not part of the user facing api? To maintain consistency with the other query builders?

Yes and I should have done that! It's been cleaned up now so the where_ix/where_col are no longer in the public api.

[joshua-spacetime]

Apologies for the long feedback loop on this one @JasonAtClockwork, but it looks like this still may be part of the public api. Is it currently possible to write an expression like this:

users.where([](const auto& cols, const auto& ix) {
    return ix.id.eq(cols.id);
});

It really should be:

users.where([](const auto& cols) {
    return cols.id.eq(...);
});

Because indexed columns are only applicable/necessary for joins.