Introduce decoupled query_constraints for associations

[nvasilevski]

Introduce decoupled query_constraints for associations

Reintroduces query_constraints on associations, decoupled from foreign_key.

Mental model

query_constraints is a list of additional columns to match when querying an
association's targets (loading and preloading). They are layered on top of the
foreign key — the foreign key always participates, because an association can't be
queried without it.

• When only foreign_key is given → behaves exactly as today.
• When both foreign_key and query_constraints are given → foreign_key handles
  writes, and querying matches on foreign_key + the extra columns.
• Listing the foreign key inside query_constraints is allowed, not rejected — it
  is de-duplicated.

Two sides of a constraint

A column can have a different name on each side. query_constraints accepts symbols
(same name on both sides) and hashes (self_column => target_column):

class BlogPost < ApplicationRecord
  belongs_to :featured_comment,
    class_name: "Comment",
    foreign_key: :featured_comment_id,
    query_constraints: [:blog_id, { id: :blog_post_id }]
  #   :blog_id              -> blog_id on both tables
  #   { id: :blog_post_id } -> BlogPost#id matches Comment#blog_post_id
end

Resulting join keys:

• self (BlogPost) columns: ["blog_id", "id", "featured_comment_id"]
• target (Comment) columns: ["blog_id", "blog_post_id", "id"]

A Hash mapping requires an explicit foreign_key (an FK can't be derived from a
renamed pair) — otherwise an ArgumentError is raised.

Implementation

• New reflection methods query_constraints_foreign_key,
  normalized_query_constraints_mapping, and
  join_query_constraints_{primary,foreign}_key / join_query_constraints_id_for.
  Join (join_scope, AssociationScope) and preload paths resolve keys through
  these, falling back to the existing join_* behavior when no query_constraints
  are present.
• active_record_primary_key (and autosave's write key) ignore query_constraints
  when an explicit foreign_key is present, so writes and .joins() keep using the
  scalar PK/FK.
• ThroughReflection / PolymorphicReflection / RuntimeReflection delegate the new
  methods in lockstep with their join_* counterparts.

Backward compatibility

Old-style query_constraints (a plain list of FK columns, no explicit foreign_key)
keeps its previous meaning: the columns become the foreign key and
normalized_query_constraints_mapping returns nil.

[hmcguire-shopify]

If the idea is that we're separating the two concepts, do we still need to copy the value over?