Fix PINNRepresentation type stability and add docstrings

[ajatshatru01]

Checklist

• Appropriate tests were added
• Any code changes were done in a way that does not break public API
• All documentation related to code changes were updated
• The new code follows the
  contributor guidelines, in particular the SciML Style Guide and
  COLPRAC.
• Any new documentation only uses public API

Additional context

Context / Background
This PR addresses the type instability issue detailed in #932. Specifically, PINNRepresentation contained 25 fields strictly typed as ::Any. Because deterministic fields (like depvars and param_estim) were fully dynamically-typed, performance penalties mounted during setup and inner loop execution of the loss functions.

As a first step towards enhancing the ModelingToolkit PINN parsing pipeline (GSoC 2026 prep), ensuring PINNRepresentation handles its types correctly is critical so that downstream symbolic AST transformations have strong guarantees.

Changes Made:-

• Concrete Field Typing: Removed ::Any types for 8 deterministic PINNRepresentation fields and provided them with strict type assertions (depvars::Vector{Symbol}, param_estim::Bool, adaloss::AbstractAdaptiveLoss, etc.).

• Optimized PINNLossFunctions: Transformed the PINNLossFunctions struct to a @concrete struct utilizing ConcreteStructs.jl (which NeuralPDE.jl already depends on) to permanently eliminate field access dynamic dispatch on the finalized loss functions without exposing massive generic parametric footprints to the user API.

• Fixed ??? Docstrings: Documented all fields correctly in both PINNRepresentation and PINNLossFunctions. Also fixed the missing ?? definitions for logger, log_options, and iteration in the PhysicsInformedNN struct.

• Dependency Handling: Migrated the AbstractAdaptiveLoss abstract type definition from adaptive_losses.jl into pinn_types.jl to correctly allow struct type boundary declarations during compilation time.

• Added pinn_types_stability_tests.jl : Added a standard @testitem that runs an end-to-end PINN discretization check tagged for the nnpde1 suite, serving as a rapid regression smoke-test for inner representation handling.

I ran the smoke test on my local machine to test if everything is correct.

The test ran all fine.
Add any other context about the problem here.

[ChrisRackauckas]

Probably unnecessary as being removed by the next parser

[ajatshatru01]

Probably unnecessary as being removed by the next parser

ah ok, works for me