chore(core): Remove km_core_keyboard_attrs.folder_path 🎼

[ermshiperete]

PR #12769 removed km_core_keyboard_load that allowed loading a keyboard from a path. Instead we now pass a BLOB to core to load a keyboard. With the function gone there is no longer a need to have a field with the path.

Follow-up-of: #12497
Related-to: #12769
Test-bot: skip

[keymanapp-test-bot]

User Test Results

Test specification and instructions

User tests are not required

Test Artifacts

• Developer
  • Keyman Developer - build : all tests passed (no artifacts on BuildLevel "build")
  • Compiler Regression Tests - build : all tests passed (no artifacts on BuildLevel "build")
  • Keyman Developer (old PRs) - build : all tests passed (no artifacts on BuildLevel "build")
  • kmcomp.zip - build : all tests passed (no artifacts on BuildLevel "build")
  • kmcomp.zip (old PRs) - build : all tests passed (no artifacts on BuildLevel "build")
• Keyboards
  • Test Keyboards - build : all tests passed (no artifacts on BuildLevel "build")
• macOS
  • Keyman for macOS - build : all tests passed (no artifacts on BuildLevel "build")
  • Keyman for macOS (old PRs) - build : all tests passed (no artifacts on BuildLevel "build")
• Web
  • KeymanWeb Test Home - build : all tests passed (no artifacts on BuildLevel "build")
• Windows
  • Keyman for Windows - build : all tests passed (no artifacts on BuildLevel "build")
  • FirstVoices Keyboards for Windows - build : all tests passed (no artifacts on BuildLevel "build")
  • FirstVoices Keyboards for Windows (old PRs) - build : all tests passed (no artifacts on BuildLevel "build")
  • Keyman for Windows (old PRs) - build : all tests passed (no artifacts on BuildLevel "build")
  • Text Editor (ARM64) - build : all tests passed (no artifacts on BuildLevel "build")
  • Text Editor (x64) - build : all tests passed (no artifacts on BuildLevel "build")
  • Text Editor (x86) - build : all tests passed (no artifacts on BuildLevel "build")

[mcdurdin]

I am not sure about this change. We have not published an API stability policy but perhaps we need to. For example GNOME's policy.

Removal of fields is not backwardly compatible; the question in my mind is if we need to maintain backward compatibility for Core because it is normally tightly linked to a release. (If we have other consumers of the Keyman Core API, then this will become a more serious question.)

If we do publish this, it is a Keyman Core API change that needs to be listed in our 19.0 changes wiki