Firngrod/improved same half logic

[firngrod]

This improves upon the same half secondary logic in that it no longer actively triggers primary from same half activations, but rather just prevents same half keys from triggering secondary role.
While there are a number of edge case changes from this, none are what I would call bugs, and I think the benefits outweigh the costs.
Benefits:

• Centralized logic: The decision is now made only in the isKeyAllowedToBeActionKey function, the rest of the code functions the same regardless of same half logic
• When using TriggerOnPress, it is now possible to use multi-mod combos. I even managed to forget I had triggerOnPress on for a brief while after testing that it worked.
• I think the naming is much more clear on this behavior than on the previous one. Let's start a discussion on it!

Arguably negative changes are mainly to do with the timing aspect. One can type out entire key sequences on the same half while a secondary role key is being held with nothing happening before the key is released, which is sort of counter-intuitive, but only actually ever happens if one is determined on testing it. Otherwise, it does ever so slightly the timing of application of some keys, but it's nothing next to just the fact of using Secondary Roles.

[kareltucek]

I think the naming is much more clear on this behavior than on the previous one. Let's start a discussion on it!

They sound fine! :-)

[kareltucek]

Do any edge cases need to be considered?

I have thought about the following, and figured it is actually the desired behavior:

• press a
• press s
• release s
• press j
• release j
• 'a' now triggers its secondary role
• if 's' is a dual-role key, it gets evaluated as primary, yet still applied as 'a+s'
• finally, j gets applied as 'a+j'
• this sounds as the desired behavior.

[kareltucek]

If you are up to it, then please do refactor the predicate part.

Otherwise, let me know and we can merge it as is.

[firngrod]

Do any edge cases need to be considered?

I have thought about the following, and figured it is actually the desired behavior:

* press a

* press s

* release s

* press j

* release j

* 'a' now triggers its secondary role

* if 's' is a dual-role key, it gets evaluated as primary, yet still applied as 'a+s'

* finally, j gets applied as 'a+j'

* this sounds as the desired behavior.

Yes, you are correct, the first key would go secondary and the two next keys would go primary with mod applied, even though the first one was from the same half.
I don't know what to call it. It's well defined and expected behavior, but not the goal behavior. Call it accepted behavior? It's an unintended usecase of the feature which I think is not going to cause any issues.

[kareltucek]

I think it actually is the correct and desired behavior the way it is :). Just took a few minutes to realize that there is nothing strange about it and that it definitely isn't expected to be a multimod scenario.

[firngrod]

I see it like if someone asked if you had considered that they new wooden wrist rest smelled differently from the rubber one. Well, yes it does, it's not really a feature that was aimed for, but it is to be expected, and no one was expected to start actively sniffing it.

[firngrod]

Once the other branch merges, I will rebase this one and start working on the changes.

[firngrod]

Baked the predicated check into the search functions.
The release from PostponerQuery_FindFirstPressed is not used. This will be fixed at some point. Right now, I want to run these settings for a day or two to make sure they're okay.

[kareltucek]

Alright, let's merge this!

Would you write a changelog entry? (A couple of brief bullet points to be shown in the release notes about all your changes to secondary roles so far. Just post it here or anywhere.)