docs: document nearby selection for basic variables in move selector reference

[mvanhorn]

Summary

The Move Selector Reference now documents nearby selection for basic planning variables: what origin and destination mean outside of list variables, and the advanced XML configuration for wiring nearbySelection into changeMoveSelector and swapMoveSelector. This covers the part of #2292 that stayed open after the heading fix.

Why this matters

#2292 was reopened by @triceo with the note that "the nearby part was not resolved". The nearby selection section of move-selector-reference.adoc only described NearbyDistanceMeter semantics and XML configuration for list variables, while the surrounding text ("In a nutshell, when nearby selection is used in a list move selector, ...") implies a basic-variable counterpart that the page never had. Anyone configuring nearby selection on a basic variable model had to reverse-engineer the selector configs to find the right XML shape.

Testing

• The new subsection mirrors the structure and anchor conventions of the existing "Nearby selection with a list variable" subsection, so no new xref targets or duplicate anchors are introduced.
• XML element names in the examples (nearbySelection, originEntitySelector, mimicSelectorRef, nearbyDistanceMeterClass) were checked against the selector config classes under core/src/main/java/ai/timefold/solver/core/config/heuristic/selector/.

Fixes #2292

[triceo]

Thanks for contributing, @mvanhorn !
Please review for correctness, @zepfred.

[zepfred]

The paragraph can be simplified. I was thinking of something like this:

In a nutshell, when nearby selection is applied, the `Origin_` and `Destination_` types are determined by the relevant selectors within the `nearbySelection` configuration. For a basic variable, `Origin_` is defined by the planning entity of the nearby definition, while `Destination_` can be either a planning value or a planning entity. As for a list variable, `Origin_` is always a planning value (for example `Customer`),
but `Destination_` can be either a planning value or a planning entity.
That means that in VRP the distance meter must be able to handle both `Customer` and `Vehicle` as the `Destination_` argument:

[zepfred]

Please add a section ID so it can be referenced in the introduction paragraph when mentioning the basic variables.

[zepfred]

Please add a section ID so it can be referenced in the introduction paragraph when mentioning the list variables.

[zepfred]

Please add the following paragraph as an [IMPORTANT] block.

[zepfred]

Suggested change

	to specify which entity should be the origin of the distance calculation.
	to specify which entity should be nearby the selection.

[zepfred]

Suggested change

	`Origin_` is the entity selected by the mimicking `entitySelector`
	`Origin_` is the entity selected

[zepfred]

Suggested change

	and `Destination_` is the planning value selected by the `valueSelector`.
	and `Destination_` is the nearby planning value selected by the `valueSelector`.

[zepfred]

Suggested change

	`Origin_` is the entity selected by the mimicking `entitySelector`
	both `Origin_` and `Destination_` are planning entities.

[zepfred]

Suggested change

	and `Destination_` is the other planning entity selected by the `secondaryEntitySelector`.
	The `Destination_` is determined by the configuration setting `secondaryEntitySelector`.

[zepfred]

Suggested change

If one distance meter is reused for both selectors,

[zepfred]

Suggested change

its `Destination_` type must accept both destination types.

[zepfred]

Let's simplify the example by removing the node variableNameIncludes.

[zepfred]

Thank you for your contribution, @mvanhorn. I have a few minor comments before I can approve it.