Fix frames in binary star systems

[sam52796]

Fixes #6312.

There were two problems with binary star systems.

Firstly, the check to ensure that star frames in binary star systems don't overlap with each other was too conservative, resulting in some child bodies being outside their parent's frame. This confused the code that expects a nice consistent frame hierarchy. The first commit rearranges the radius checks to ensure that frames always encompass their children. The problem seems to only occur in custom binary systems, where the designer might have put planets further out than the procedurally generated code would place them. But now you have a better chance of entering frames correctly in custom binary systems.

The second issue isn't really an issue, but when the player is in a grav point frame, the HUD just doesn't show any frame of reference at all, which can be confusing, even when the frames are working correctly. So the second commit displays the frame label in these cases, to reassure the player that everything is still okay. Actually having a full velocity and position readout would require deeper changes to the code, which assumes that there is no Body object for gravpoints, while all the existing HUD display properties refer to Body attributes. So this is kind of a patch, but a relatively safe one.

Note that for #6312 specifically, since the system body tree is stored in the save file, if you load that game after this fix is applied you will still see the problem. You have to jump out of the system and then back in before you can crash into Eternal.

[fluffyfreak]

The reason for the extremely conservative check on frame size is that we can have an opposite problem whereby another body with it's own frame is inside the frame of it's parent, or grandparents, frame which prevents ships from correctly switching to that bodies frame.

I think it would be worth testing for this, I think #5885 is an example of it though I believe there are others

[bszlrd]

If generated systems are fine, then how about adding the ability to hand-define the frame sizes in costum systems? With visual feedback in the editor.

[sam52796]

For physically sensible Keplerian body trees, I think that the frame calculations should always turn out logically correct. So any situation where a custom frame radius is required indicates that the system has a layout issue. I think that allowing a custom frame radius is more likely to increase the occurrence of bugged systems. So I don't see the need for that, unless the game plans to include high-Kardashev civilizations who have edited solar systems to otherwise impossible gravitational configurations.

However, if this is a common problem then maybe the editor could include a toggle to show frames, so that designers can see in advance if something will go wrong with their current layout.

[bszlrd]

I was saying that mostly as a simpler solution, if the other is too complicated. I'd prefer an astronomically correct solution. Showing the frames in the editor would be nice anyhow.
Unrelated, but it would be nice to have that in the in-game system map as well eventually. At least the point of frame change and predicted orbit form there, like in KSP

[sam52796]

Just to clarify, since this is potentially confusing - in the current master branch there are two issues with frames:

One is that in certain circumstances in sensibly-laid-out binary star systems, the code that calculates the frames is slightly too conservative, resulting in some outer planets not being within their parent star's frame. This pull request addresses that.

The second problem is that sometimes systems are not sensibly laid out, for example in #5885 and #6302, where some planets have moons in orbits that span the solar system and overlap with the star itself. In those cases, the frame calculation code has no chance, because there is no logical frame tree possible. The solution in those cases is to fix the system layout, and that's what my other pull request #6330 does.