FEAT: configure backend precision

[redeboer]

• Closes Make JAX precision configurable while defaulting to 64-bit #576
• Closes Make TensorFlow precision configurable while defaulting to 64-bit #577

✨ New features

• Add a public tensorwaves.configure() API for independently selecting 32-bit or 64-bit precision in JAX and TensorFlow without eagerly importing optional backends.
• Use 64-bit backend precision by default while respecting JAX_ENABLE_X64 unless an explicit JAX precision is configured.

🐛 Bug fixes

• Apply the configured precision consistently when creating backend functions, gradients, lambdified expressions, and TensorFlow random values.

📝 Documentation

• Document when and how to configure backend precision, including initialization timing and environment-variable precedence.

Squash commit messages

* DOC: document backend precision configuration
* FIX: apply configured precision consistently

[redeboer]

Verified downstream with TensorWaves at 2c97d7c: the default is still 64-bit. JAX initially reports jax_enable_x64=False, but first TensorWaves JAX-backend initialization switches it to True; resulting arrays are float64/complex128. Setting JAX_ENABLE_X64=0 before startup instead produces float32/complex64 as intended.

I also ran six affected jpsi-nstar test fits in both modes. Aggregate wall time was about 612 s (FP64) versus 522 s (FP32), nominally 1.17x faster. That number is misleading, however: the largest speed-up coincided with a worse minimum (-2969.72 vs -2461.82), and xNES landed in a completely different basin (-1480.62 vs +2034.93). Across the four fits with comparable NLLs, FP32 was not faster overall (about 258 s vs 252 s). For these CPU fits, FP32 therefore offers no convincing end-to-end benefit at equivalent fit quality and noticeably reduces optimizer stability; keeping FP64 as the default looks appropriate.