refactor(web): generalize SearchQuotientSpur parent requirements 🚂

[jahorton]

As an upcoming goal is to introduce a new SearchQuotientNode type that will assist with context-caching across multiple tokenizations, it is wise to generalize SearchQuotientSpur and functions utilizing it to accept any SearchQuotientNode-implementing type as its parent.

Build-bot: skip build:web
Test-bot: skip

[keymanapp-test-bot]

User Test Results

Test specification and instructions

User tests are not required

Test Artifacts

• Web
  • KeymanWeb Test Home - build : all tests passed (no artifacts on BuildLevel "build")

[mcdurdin]

I think this is okay. It's very hard to tell if there are logic changes at all. But LGTM

[jahorton]

I've now reworked this PR and split it into multiple segments focused on each individual "moving part". Hopefully that'll make the changes easier to follow.

[mcdurdin]

Given this we should probably lean towards using the unitTestEndpoints pattern?

[jahorton]

After a bit of thought, I opted for a different option - it's now a standalone method that is no longer part of the type.

Among other things, this also allows it to be tree-shaken easily.

[mcdurdin]

Not sure why you don't want to use the accepted pattern but this is at least better than before

[jahorton]

I am a bit curious how that works when declared on an interface, admittedly.

Looking at https://github.com/keymanapp/keyman/wiki/Unit-Tests#typescript, would it be best to wrap that standalone function in its own unitTestEndpoints separate from the interface?

[mcdurdin]

For interfaces, it probably doesn't work. But you could export a unitTestEndpoints-style interface that can be cast to?

For the function quotientPathHasInputs in question, rather than exporting it directly, have:

export const unitTestEndpoints = {
  quotientPathHasInputs,
};