Improve interface compliance for generic numeric types

[ChrisRackauckas-Claude]

Summary

• Replace hardcoded Float64 arrays with type-generic alternatives in three files
• Tested with Float64, Float32, and BigFloat to verify type genericity
• All changes maintain backward compatibility with existing Float64 usage

Changes

• discretize.jl: Use eltype(cord) for zeros() and Matrix construction in get_numeric_integral() to support BigFloat and other numeric types
• training_strategies.jl: Use eltypeθ parameter in get_points_loss_functions() for zeros() and ones() to maintain type consistency
• advancedHMC_MCMC.jl: Use type parameter T in zeros() call for consistency with the rest of the function

Interface Compliance Testing

Tested with JLArrays (GPU-like arrays) and ArrayInterface.jl to verify:

• safe_get_device correctly identifies device for JLArrays
• EltypeAdaptor works with different array types
• fast_scalar_indexing is respected (JLArrays return false)

Tested with BigFloat to verify:

• NNODE solver works with BigFloat inputs and outputs BigFloat solutions
• PhysicsInformedNN works with BigFloat domains
• No hardcoded Float64 prevents type propagation

Test plan

• Verified Float64, Float32, BigFloat work with NNODE
• Verified Float64, Float32, BigFloat work with PhysicsInformedNN
• Verified JLArray compatibility for device detection
• Package still loads correctly after changes

cc @ChrisRackauckas

🤖 Generated with Claude Code