[robotpy] Try to fix opmodes

[pjreiniger]

I took a stab at trying to fix the stubgen problem for the opmode addition. I essentially "started over" when it came to all the python stuff, and tried to make small commits that @virtuald could look at.

I started at 44cf645632, as this was the last commit that was recently synced up with mostrobotpy.

I did a poor mans rebase -i by cherry-picking all of the non opmode commits since then:

# Pre Opmodes
git cherry-pick -n -x 936be71a7d 06a9a055b3 5aaf2d7138 cbe447aad7 d830c41063 cca035787c 13abb3d332 0049c6f23f 2a41b80e00
# Post opmodes
git cherry-pick -n -x af0a3e9c2f e2c9af862e f9ee67e85f f668e10197 718f2f7ccd 6ef55654f6 5bebaebcc0 5a22abb85b e2d492ac3f d6b54bbae2 a38499dcd7 0349524f80
git commit -m "cherry-pick + squash non-opmode related changes"

I then did a hacky "partial merge" where I grabbed all of the opmode changes excluding the vast majority of robotpy changes. There are a coulple of robotpy changes, like the pure python OpModeRobot and some bug fixes, but overhwelmingly it definitly "reverts" the yaml changes

git cherry-pick -n -x dacded37e5 ea71bdfba6 bcb5c5c16c f6ef155166 8b10a0546d 7cb58962c5
git reset
git checkout wpilibc/src/main/python/semiwrap hal/src/main/python/semiwrap hal/src/main/python/pyproject.toml wpilibc/src/main/python/pyproject.toml wpilibc/src/main/python/wpilib/src/rpy wpilibc/src/main/python/wpilib/__init__.py
git clean -fd wpilibc/src/main/python/semiwrap hal/src/main/python/semiwrap
git add .
git commit -m "Partial merge"

The next commit runs scan-headers and update-yaml AS IS, to give a base for what the C++ changes were.

One of the core problems with the wrapper is that there is both a HAL_ControlWord (which gets trimmed to ControlWord for the python binding) and a wpi::hal::ControlWord (which also would normally get trimmed to ControlWord for the binding). The same is also true HAL_RobotMode / wpi::hal::RobotMode. Unfortunately both versions are exported as part of the interfaces as currently written, so it isn't as trivial as just ignoring generating bindings for them without massive cascading effects. I found a way to rename them and then a lot of stuff just seemed to work ™️

Another one of the big problems is that HAL_OpModeOption uses WPI_String as a member type. This fix involved ignoring + adding a property_readonly for those fields, and creating an inline copy function for GetOpModeOptions

A lot of the "trivial" fixes like ignoring the "Register..Callback" functions or adding extra_includes remain the same as what is already landed on 2027, but I was able to get away with ignoring less of the bindings

These changes should allow the stubgen process to actually build now. I tested it with a local bazel-ified version of what mostrobotpy does that is hacky and not landable, but was first able to reproduce the failures I'm seeing in mostrobotpy, as well as them going away with these changes.

I also added a unit test that matches the C++ one and excercies some of the more annoying fixes, so at the very least that is an improvement.

[pjreiniger]

Note I now have this stacked on #8500. They can be landed together here or in separately one at a time

[virtuald]

So, this is more for your education than a change we should make here, but over time I've moved towards creating python list objects directly instead of using std::vector because it avoids doing a second set of copies.

See https://github.com/robotpy/mostrobotpy/blob/80bffec30fe78a274e362c92a566e79271c1b8bc/subprojects/robotpy-wpiutil/wpiutil/src/wpistruct/wpystruct_fns.cpp#L136 for what I mean. Note that the function returns py::typing::List<Type> which ensures a nice type signature in autocomplete. Just returning a py::list wouldn't tell the user the type of the element (but just returning the std::vector does because the type caster will take care of that aspect of it.

I don't know how often we expect this to get called so it probably doesn't matter.

[virtuald]

This is going to leak memory because there's no destructor for HAL_OpModeOption?

[ThadHouse]

Not directly related to this, but we have a leak in the JNI wrappers for WPILib as well.

[ThadHouse]

Realistically, are the python level strings valid through the entire call, and utf8? If they are, you can make the wpi_strings in this be a view over the python strings, rather than a copy. If not then yeah you'll need to free afterwards.