planner: make tidb_enable_non_prepared_plan_cache_for_dml independently control DML plan cache

## Enhancement

Currently, `tidb_enable_non_prepared_plan_cache_for_dml` only takes effect when `tidb_enable_non_prepared_plan_cache` is also enabled. This makes the DML-specific switch not independently useful: operators cannot enable non-prepared plan cache for DML workloads without also enabling the ordinary non-prepared plan cache path for SELECT statements.

Expected behavior:

- `tidb_enable_non_prepared_plan_cache_for_dml=ON` should allow supported DML statements to use non-prepared plan cache even when `tidb_enable_non_prepared_plan_cache=OFF`.
- `tidb_enable_non_prepared_plan_cache=ON` should continue to control ordinary non-prepared SELECT statements.
- DML statements should remain disabled when `tidb_enable_non_prepared_plan_cache_for_dml=OFF`, even if the general switch is ON.
- Existing non-prepared plan cache eligibility checks and unsupported-statement safeguards should still apply.

Motivation:

This provides a narrower rollout knob for DML plan-cache optimization and avoids coupling DML behavior to the general non-prepared plan cache switch.

Scope:

- INSERT / UPDATE / DELETE
- SELECT ... FOR UPDATE if it is handled as DML by the existing non-prepared plan cache checker
- No change to prepared plan cache semantics

Start at the existing non-prepared plan cache checker and trace how tidb_enable_non_prepared_plan_cache and tidb_enable_non_prepared_plan_cache_for_dml gate INSERT, UPDATE, DELETE, and SELECT ... FOR UPDATE. Preserve the existing eligibility and unsupported-statement checks; done means the two switches independently produce the expected DML and SELECT behavior without changing prepared plan cache semantics.

Written by the indexing model from the issue text.