`find_with_related` implicitly adds ordering on `left.id`

Description

find_with_related implicitly adds an order by on the left table's id. This is extremely unintuitive; for instance:

LeftEntity::find()
  .find_with_related(RightEntity)
  .filter(...)
  .order_by(LeftCol1, Order::Desc)
  .order_by(LeftCol2, Order::Desc)

generates a query that is ordered by (LeftId, LeftCol1, LeftCol2) rather than (LeftCol1, LeftCol2), as might be expected.

Steps to Reproduce

1. Write a query using find_with_related that includes an order_by after the find_with_related
2. Either try to execute it, or .build(..).to_string() it
3. Observe that the order clause has order by left.id asc prepended to it

Expected Behavior

In the example case from the description, I would expect the ordering to be (LeftCol1, LeftCol2).

Actual Behavior

In the example case from the description, the actual ordering is (LeftId, LeftCol1, LeftCol2).

Reproduces How Often

Deterministically.

Workarounds

Placing the order_by before the find_with_related, like so:

LeftEntity::find()
  .order_by(LeftCol1, Order::Desc)
  .order_by(LeftCol2, Order::Desc)
  .find_with_related(RightEntity)
  .filter(...)

produces an ordering on (LeftCol1, LeftCol2, LeftId), which is acceptable. However, the fact that the query needs to be constructed in this manner is very non-obvious.

Reproducible Example

See description

Versions

├── sea-orm v0.12.15 (*)
├── sea-query v0.30.7 (*)
│   ├── sea-orm v0.12.15 (*)

Start by reproducing the Rust query shown with find_with_related, order_by, and build().to_string(), then inspect the SeaORM code path for find_with_related ordering. Done means ordering added after find_with_related no longer places left.id before the requested columns, while the documented workaround behavior remains covered by a regression test.