[apriltag] Add AprilTagFieldLayout.loadField() and deprecate AprilTagFields.loadAprilTagLayoutField()

[KangarooKoala]

Fixes #6326.

AprilTagFields.loadFromResource() uses AprilTagFieldLayout.loadStandardField() instead of the other way around so that it's easier for people to follow the call path. (Don't need to go to a different class)

[calcmogul]

Java version looks good. Just needs a C++ port.

[KangarooKoala]

This PR is technically breaking because now including AprilTagFields.h doesn't include the declarations in AprilTagFieldLayout.h. I *could* fix this by adding #include "frc/apriltag/AprilTagFieldLayout.h" at the bottom of AprilTagFields.h (I tested this locally and it works), but I don't think that's behavior we want to support in the first place.
On another note, do we still want to deprecate the factories outside of AprilTagFieldLayout (as mentioned in the original issue)? If the core problem is discoverability, then I don't see a particular reason to deprecate and remove the other factories (though I don't have a particularly strong reason to keep them either)- Maybe there's something I'm missing?

[calcmogul]

I'd prefer there be only one obvious way to do it, so the old, more hidden way would be deprecated. I also dislike how the old function uses LayoutField, which is just asking for users to get it backwards.

[calcmogul]

After internal discussion, we don't want to deprecate the function in the middle of the season. What we could do instead is merge this without the deprecation into main, then merge the deprecation on the development branch.

[KangarooKoala]

I don't know if it'd be easier (for when development and main are reconciled after the season) to a) merge #6377 and this PR separately into their respective branches or b) to merge #6377 into both and then have a different PR targeting development that's just the deprecation. For now I'm going with the separate PRs approach. (And side note, git cherry-pick made #6377 absurdly easy)

[KangarooKoala]

Closing in favor of #6550.