Fix/lwt routing lbp filtering 384

[nikagra]

Addresses #384.

Problem

LWT statements were routed by CqlRequestHandler using the raw replica set from the token map, without going through the configured LoadBalancingPolicy. In clusters using TokenAwarePolicy together with DC-/rack-aware policies, this caused LWT traffic to ignore those policies and be sent to replicas in a fixed order, potentially preferring replicas in a different DC or rack than expected.

Approach

• Introduce two new routing hints on the public API:
  • RequestRoutingType (REGULAR, LWT) to distinguish LWT from non-LWT requests.
  • RequestRoutingMethod (REGULAR, PRESERVE_REPLICA_ORDER, TOKEN_BASED_REPLICA_SHUFFLING) to control how replicas are ordered and shuffled.
• Extend Request with:
  • @Nullable RequestRoutingType getRequestType()
  • default RequestRoutingMethod getRoutingMethod()
• Update all built-in statement and graph-statement implementations (Simple, Bound, Batch, graph statements, PrepareRequest, etc.) to report the appropriate RequestRoutingType (LWT vs regular).
• Remove the LWT-specific replica lookup from CqlRequestHandler; routing for LWT and non-LWT statements is now delegated entirely to the load balancing policy via DefaultLoadBalancingPolicy.newQueryPlan.
• Refactor DefaultLoadBalancingPolicy:
  • Derive the replica set for the request when available.
  • For LWT requests, build the query plan directly from the replica set instead of from all local-DC nodes.
  • For non-LWT requests, preserve the existing behavior (local-DC live nodes, replicas bubbled to the front).
  • Factor the replica reordering and health-based reordering logic into helpers, and make shuffling logic depend on RequestRoutingType so that LWT statements are not constrained to a single rack.
  • Honor RequestRoutingMethod.PRESERVE_REPLICA_ORDER by skipping shuffling when replica order must be preserved.

Impact

• LWT routing now flows through the configured LoadBalancingPolicy, so DC-/rack-aware policies are respected instead of being bypassed for LWT traffic.
• Non-LWT routing semantics remain unchanged.
• The public API is extended in a backward-compatible way (new enums and methods with defaults); existing client code continues to work, while advanced users can make use of the new routing hints.