Global Views in PhasorDynamics SystemModel using new Vector

[lukelowry]

Description

This PR updates PhasorDynamics so buses and components use their slices of the SystemModel state vectors directly. This removes the local state copy path and keeps component accessors consistent with the integrator-updated system state.

Partially addresses #96. Related to #145.

Proposed changes

• Added StateVector support so GridElement can own standalone state or alias SystemModel state.
• Updated SystemModel allocation to bind each bus/component to global state and verify element sizes remain fixed.
• Updated Enzyme call sites to use the explicit yData() accessor for live state pointers.
• Added a PhasorDynamics system test for element/system state aliasing.

Performance was measured with application/PhasorDynamics/PDSim using the app-reported Complete in time. Each row reports the median of 3 trials after rebuilding PDSim on the corresponding branch.

Case	develop (s)	This branch (s)	Improvement
Hawaii	0.201302	0.165187	17.9%
NewEngland	0.272596	0.220406	19.1%
Illinois	0.664262	0.592922	10.7%
WECC	1.203380	1.045540	13.1%
Texas	9.063860	7.515690	17.1%

Checklist

• All tests pass. (except the known PE failure)
• Code compiles cleanly with flags -Wall -Wpedantic -Wconversion -Wextra.
• The new code follows GridKit(TM) style guidelines.
• There are unit tests for the new code.
• The new code is documented.
• The feature branch is rebased with respect to the target branch.
• N/A: no CHANGELOG.md update is needed for this internal PhasorDynamics state-storage change.

Further comments

This work was motivated by the addition of IEEEST stabilizers: adding 333 stabilizers to the Texas case dramatically reduced performance, and this change removes avoidable state-copy overhead in PhasorDynamics system evaluation.

NOTE: I had to make a new PR but this is revival of #411

[PhilipFackler]

I like the VectorView class. I don't think this is the right way to use it. We could use it in the way that, while touching a lot of files outside PhasorDynamics, would only change the API (not the implementation) for those classes. I'm going to explain my thinking even though, given your comments in the last meeting, you've probably had these ideas already. :)

1. The abstract functions defined for Evaluator should return one of these.

That is,

      virtual std::vector<ScalarT>&       y()       = 0;
      virtual const std::vector<ScalarT>& y() const = 0;

becomes

      virtual VectorView<ScalarT>       y()       = 0;  // no `&` needed
      virtual VectorView<const ScalarT> y() const = 0;

This means that the Evaluator API doesn't care if a subclass is owning or non-owning.

2. VectorView would need (non-explicit) constructor(s) to convert from [const] std::vector<T>&. This would allow for Evaluators outside PhasorDynamics to still return their std::vector members from those Evaluator functions.

3. In PhasorDynamics, Component (and BusBase) can use Slaven's Vector directly for these variables. SystemModel as a Component would own its data in the normal use-case, and components would not. (This also makes conceivable the possibility of a SystemModel also being non-owning in a hierarchical system.)

4. Then we would just need a conversion from Vector to VectorView; either another constructor for VectorView or a method on Vector (Vector::getView())...or both.