In the Philippines, Senior Citizens (SC) and Persons With Disabilities (PWD)
are legally entitled to statutory discounts and VAT exemptions on eligible
goods and services. The `l10n_ph_invoice` module already handles these on
customer invoices and credit notes; this extends the same privileges to
quotations and sale orders.

This adds a new `l10n_ph_sale` module, enabled like `l10n_ph_invoice` via a
separate "Discount Privileges on Sale Orders" toggle in the Philippine
Accounting settings (`module_l10n_ph_sale`, defined in `l10n_ph` next to the
invoice toggle). It mirrors the invoice implementation:

* Sale Order Line: `sale.order.line` inherits the shared
  `l10n_ph.discount.privilege.line.mixin` and provides the model-specific
  hooks (`_l10n_ph_get_discount_price_details` recomputes the gross amounts
  with the tax engine) plus helpers to adjust the price unit and taxes from
  the privilege's fiscal position. Privilege fields are propagated to the
  generated invoice lines in `_prepare_invoice_line`, so invoiced lines
  behave exactly like lines the privilege was applied on.
* Application Wizard: `l10n_ph.discount.privilege.wizard` is extended with
  `order_id` / `sale_order_line_id` so the same preview / scope-filtering /
  apply / remove-all / single-line-remove flow works on draft and sent
  quotations and sale orders.
* Sale Discounts interplay: privileged lines are excluded from the standard
  sale Discounts wizard to avoid double discounting.
* Views: "Discount Privileges" buttons below the order lines, regular/special
  discount amount columns, and the line discount becomes readonly while a
  privilege is applied.
* Security: salesmen get read access to privilege definitions and CRUD on the
  wizard; configuring privilege definitions remains reserved for Accounting.
* Tests: coverage for the wizard flows, scopes, fiscal position mappings,
  discount computations, state guards, access rights, invoice propagation and
  the sale Discounts interplay.

Task-6032201

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Circular 200/2014/TT-BTC requires a "Sổ Nhật ký chung" (S03a-DN) next to the general ledger (S03b-DN): the same journal items, but listed entry by entry in chronological order instead of account by account.

Add it as a second Vietnamese variant of the general ledger root report, reusing the S03b-DN counterpart matching engine. Grouping by account.move implies a few differences: the query uses the 'strict_range' scope, since a journal reports the movements of the period and carries no opening balance; move_id is a custom groupby, so that the chronological order is kept; lines are labelled with the account they hit, which the move group no longer shows; and the account-centric post-processing of the general ledger is dropped.

Also order the rows of _fetch_full_move_rows, which had no ORDER BY. The order in which Postgres returned them decided the order of the split rows produced by the proportional counterpart matching, making both S03a-DN and the existing S03b-DN report non-deterministic.

task-6089050