GetOrbitalStateVectorsAtUT() is particularly whack in the way that it applies the inverse rotation constructed at a future time via using Planetarium.ZupAtT(). That means that for the most part it is only useful for constructing values which can only be compared to other vectors constructed at the same time. This bug only occurs when the vessel is below the inverse rotation threshold, though, so most of the time works fine when there's no rotation being applied.
The changes to RightHandedStateVectorsAtUT mean that we apply our own rotation in the current frames rotation to get RH rotating vectors. This is consistent with the old API, but should probably be retired and everything migrated to RH non-rotating vectors now that I can see how to get them out of the API correctly.
This may also fix other bugs in consumers of the underlying maneuvers class (e.g. rendezvous autopilot, etc).
These use GetOrbitalStateVectorsAtUT() which is problematic, they don't call Init() and have other sketchy looking behavior and nothing has used them in awhile.
Prevent Reflection errors from other mods tanking MJ
Avoids using the KSP.IO.File.Exist<T>() API that walks the loaded assemblies and throws, looking for the path to the assembly with the type T.
The MuUtils helper replicates the side effect of this API of creating the directory.
Since we construct the path afterwards anyway to load the file the only reason I can see for the reflection-driven-API is for that side-effect, and to cause weird bugs if someone ever moves the DLL location around and makes the two APIs start to disagree. (commit: d6adb4e)
Don't try to set the SMA based on desired altitude, but just circularize at whatever the apoapsis actually is.
We could try to circularize at the precise altitude if the desired altitude < apo, but that could get more costly so I'm going to skip thinking about it (some people will want it, some people probably won't, heuristics will add more edge conditions and buttons and I don't think it is worth it).