Remove strict WPILib version requirement

[Gold856]

Description

We're reversing course on pinning to an exact WPILib version (done in #1772) because it's unnecessarily restrictive and means people will need to wait for us when a new WPILib version releases. All issues actually seem to trace back to OpenCV; Gradle will correctly select the latest WPILib version as declared by the robot project, even if a team library depends on an older version. OpenCV is just weird in that the different versions are spread out across different group IDs, so they register as separate dependencies.

Potential issues considered were that people would forget to update the WPILib version and accidentally use the old layout, but that also causes a bunch of issues in PhotonPoseEstimator et al for similar reasons, and it seems to be well understood that you need to update to get the new field layout.

Meta

Merge checklist:

• Pull Request title is short, imperative summary of proposed changes
• The description documents the what and why
• If this PR changes behavior or adds a feature, user documentation is updated
• If this PR touches photon-serde, all messages have been regenerated and hashes have not changed unexpectedly
• If this PR touches configuration, this is backwards compatible with settings back to v2025.3.2
• If this PR touches pipeline settings or anything related to data exchange, the frontend typing is updated
• If this PR addresses a bug, a regression test for it is added

[mcm001]

I'm ok removing the wpilib version check. It sounds like within a FRC year, ABI breaks would be communicated and be loudly breaking. The FRC year in the vendor JSON gets us a first level of protection, although I'm curious how it would fail if symbols were added in a newer wpilib version than a team was using -- we'd loose all control over that, and if we wanted to avoid that, we'd be stuck using only symbols from a kickoff release right?

[Gold856]

Yep. We must build against the kickoff release to ensure compatibility for everyone.

[mcm001]

Which I'll note we don't currently do. That seems perhaps overly conservative though

[mcm001]

Approving because I think that the FRC year is sufficient for now, although my earlier comment about symbols still stands I think