[fv_*] Add NCAPS modifier to some rules to avoid inconsistent matches

[darcywong00]

Prep for the upcoming Keyman 15 release

The upcoming kmcmp.exe release will generate warnings about inconsistent matches needing NCAPS (keymanapp/keyman#6347)

 Other rules which reference this key include CAPS or NCAPS modifiers, so this 
rule must include NCAPS modifier to avoid inconsistent matches

Many of the FV keyboards also have this extraneous allkeys store which was a workaround for a very old Keyman bug and can now be removed

store(allkeys) 'abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890-=[]\;,./`~!@#$%^&*()_+{}|:"<>?' "'"
+ any(allkeys) > index(allkeys, 1)

This is a container issue for applicable FV keyboards. I'll associate PRs to this issue as I find the affected keyboards.

Tagging @madebybridget

[DavidLRowe]

From @madebybridget via slack: "As long as there is no functionality changes to the keyboards themselves (key layouts as an example), no need for me or Clarissa to review! Thanks for checking with me."

[LornaSIL]

I think these keyboards still have store(allkeys) fv\fv_gitsenimx fv\fv_kanienkeha_e fv\fv_ktunaxa fv\fv_migmaq fv\fv_nisgaa fv\fv_secwepemctsin fv\fv_sencoten fv\fv_tsekehne fv\fv_xaislakala

[darcywong00]

The NCAPS portion of the description can probably be ignored due to #1883

[LornaSIL]

@mcdurdin if we were to remove "store(allkeys)" would that be considered a non-functional change? Thus, we wouldn't need to bump the version?

[mcdurdin]

@mcdurdin if we were to remove "store(allkeys)" would that be considered a non-functional change? Thus, we wouldn't need to bump the version?

Yep, I think that'd be fine.

Mind you, some purists would say any code change, whether functional or no, should require a version bump. That way you can track changes in behavior which don't match assumptions...