feat: support optionValue in reference inputs

[louzhedong]

Adds optionValue support to ReferenceInputBase / useReferenceInputController so reference inputs can load the current record by an alternate key instead of always assuming id.

This keeps the default id behavior unchanged, but when optionValue is provided it:

• fetches the current record with getList filtered by that field
• keeps the current record in allChoices
• avoids getMany for that lookup path

Verification:

• node_modules\.bin\jest.cmd packages/ra-core/src/controller/input/useReferenceInputController.spec.tsx --runInBand
• node_modules\.bin\jest.cmd packages/ra-core/src/controller/input/ReferenceInputBase.spec.tsx --runInBand
• node_modules\.bin\tsc.cmd --noEmit -p packages/ra-core/tsconfig.json

[louzhedong]

Follow-up: I fixed the lint/typecheck regression in useReferenceInputController and re-validated locally with:

• eslint packages/ra-core/src/controller/input/useReferenceInputController.ts packages/ra-core/src/controller/input/useReferenceInputController.spec.tsx
• prettier --check packages/ra-core/src/controller/input/useReferenceInputController.ts packages/ra-core/src/controller/input/useReferenceInputController.spec.tsx
• jest --runInBand --runTestsByPath packages/ra-core/src/controller/input/useReferenceInputController.spec.tsx

At this point the remaining PR checks I can see are the external Vercel authorization gates, so there doesn't seem to be another code-side blocker on the branch.

[fzaninotto]

Relationships in react-admin require that fkeys target the id field in the related table. If this is not your case, you can either map this logic to your data model in the data provider, or use other components than react-admin's ReferenceInputs.

This is a foundational design decision that we won't challenge - it would have huge implications across the framework.

So I'm sorry, but we won't merge your PR.