Consider alternate ways for combos to support source locality behaviors for splits

[caksoylar]

While #2409 added support for global and source locality behaviors for behaviors invoked from other behaviors, currently combos only triggers source local behaviors on the central, not the part that the combo key positions reside in.

Alternatives to this should be considered, where the triggering part could depend on the key-positions that the combo uses. A few options (discussed in Discord and in some earlier messages):

1. Always triggers on central (current behavior)
2. Triggers on all parts for keys used in key-positions
3. Triggers on the part for keys used in key-positions if all are on same part, else on central
4. Nothing happens

I think 1. is helpful for dongle scenarios, but is unintuitive if all positions are on the same part. 3. would help support the dongle scenario and would be my preference but I can see 2. also be a good solution, especially with #1616.

Supporting 2. and 3. would be a non-trivial code change but if there is consensus on the best way to go about it then it would be worth working on implementing it.

[Nick-Munnich]

A more complicated solution, but the one that I would prefer, is if we could ban source local behaviors from existing in their current form and instead require that the "target" be specified in the behavior. This would require a bunch of work allowing the different peripherals to be referenced reliably and correctly in code, but that would probably be a worthwhile thing to do eventually anyway.

EDIT: That would also simultaneously resolve #2499

[caksoylar]

I think that could be considered an extension of #1616. But like you said the infrastructure to assign consistent indices to split parts isn't here yet, I believe.