SearchKit - Add static groups and organize main entity selector

[colemanw]

Overview

Adds static (non-smart) groups to SearchKit, and organizes main entity selector to be less cluttered, with primary entities up top and the rest within a collapsible optgroup.

Comments

I started doing the declutter work because selecting a group join is confusing. There are currently 3 ways to join on group (created by, modified by, plus the actual join on GroupContact which is the one 99% people want to use over the other two). That circled my mind back to a previous conversation about basic vs advanced modes, and I thought a collapsible optgroup would help a lot towards that end.
In this PR I didn't get as far as organizing the join selectors, so far the declutter just applies to the main entity selector, but it's a start and this PR is getting quite large, so it'd be good to get it merged and I'll keep at it...

[civibot]

(Standard links)

• If this is your first pull-request for CiviCRM, please browse CONTRIBUTING.md for information about the development and testing processes.
• If you are reviewing this pull-request, you may wish to consult the test sites and the Review Standards (long template, short template).

[eileenmcnaughton]

@colemanw
Test Result (2 failures / +2)

api.v4.Action.FkJoinTest.testBridgeJoinTags
api.v4.Action.FkJoinTest.testBridgeJoinRelationshipContactActivity
-- | --

[eileenmcnaughton]

So I like what you have done on organising the main selector

I think it needs to be documented - probably in this page

https://docs.civicrm.org/dev/en/latest/api/v4/architecture/

[eileenmcnaughton]

This adds in - I think the 3 fields are confusing but that isn't new to this PR and I think it DOES make the non-smart group ness clear - should we also state non-parent groups there?

[eileenmcnaughton]

@colemanw I have a couple of comments - I'm OK with this being merged & those things being addressed as follow ups - as long as they are

[eileenmcnaughton]

Re docs - it might make more sense to add a new search kit section - the bridge entity and the primary secondary stuff need documenting - I did test that for existing entities without primary/secondary defined they defaulted to secondary. I didn't test the changes to bridge entities as these seemed to be only used in core and they still work in core - eg contributions with payments listing

[colemanw]

Yes I thought "Secondary" was a good default, since extension authors won't necessarily think about it when they add a new entity.