Remove groups from blueprints panel

[Wumpf]

What

• Fixes Deprecate "groups" as a concept from the DataResultTree. #4441

Ui changes were almost trivial, all the devil in the details is which exact property overrides are shown and edited where, mostly by virtue of that never showing up because of groups

Today, we have two kinds of overrides: individual & recursive which together get accumulated. The rule for accumulated is to combine for each entity all of it's parent recursive item with its single local individual one. Note that combination rules are a bit strange at times and have no concept of "this was not edited", e.g. a thing is visible if both parties are visible with no regard to whether any of the sources has actually been set (no tri-state as would be mandated by upcoming property overrides!)

Before, any edit on a group edited recursive and any edit on an entity path edited individual. Easy!
Now we'd arguably always like to edit recursive but if we were not to show accumulated things get extremely messy as you're not editing what you see.
So instead for now I went the path that visibility edits on the blueprint panel edit recursive and indicate accumulated visibility by greying out - the eye icons however are strictly following recursive. Everything on the selection panel both shows and edits individual.
This way we don't run into strange cases where looking at a thing gives us edits (like showing accumulated but editing something else would cause continuous edits without effect!) but it's overall a pretty bad scheme.

@abey79 and me discussed this situation for a bit and concluded what we'll have to embrace the null-state (often less correct dubbed tri-state: null, visible, invisible) given by component overrides one way or the other, especially to support cases like having visible objects with a parent that inherits invisible otherwise. While there's still many open questions, I believe that we should have null-states everywhere with a simple inheritance scheme of "inherit until non-null is found". The elegance in that is that "accumulated == override if override set" - to cement that I'd propose to drop individual for the forseeable future.
The tricky thing with this is that each ui element needs to present "not set" in some way and allow to reset it.

Checklist

• I have read and agree to Contributor Guide and the Code of Conduct
• I've included a screenshot or gif (if applicable)
• I have tested the web demo (if applicable):
  • Using newly built examples: app.rerun.io
  • Using examples from latest main build: app.rerun.io
  • Using full set of examples from nightly build: app.rerun.io
• The PR title and labels are set such as to maximize their usefulness for the next release's CHANGELOG
• If applicable, add a new check to the release checklist!

• PR Build Summary
• Docs preview
• Examples preview
• Recent benchmark results
• Wasm size tracking

[Wumpf]

this is wrong and fixed in follow-up PR: direct_included should still just use is_included. But the if check here indeed wants to work with is_exact_included

[abey79]

At this point, I'm still confused by the meaning of "accumulated" and "recursive". Why isn't this the same thing? Also, why is recursive_properities and option. Shouldn't a data result always inherit from some properties?

[abey79]

hmm nvm, coffee finally kicked in. Still probably worth expending a little bit in the comments, because the nomenclature is non-obvious.

[Wumpf]

I can expand on it similar to how I did in the pull request description here. Would that help?

[abey79]

As discussed, let's fix the semantics first before patching up with comments :)

[abey79]

I took a look mainly for learning purposes, but FWIW I loved how much code got removed and the simplification of the DataResult API. I didn't catch anything shocking. Well, except for the entire property cascading story that we already discussed...