feat(hid): add optional vendor-defined selector key (vkey)

[akira-toriyama]

What

Add CONFIG_ZMK_HID_VKEY (default n). When enabled, ZMK gains:

• an independent vendor-defined HID top-level collection that reports a single
  1-byte selector — the "vkey id" (1–255; 0 = released) — on a
  configurable vendor usage page (CONFIG_ZMK_HID_VKEY_USAGE_PAGE, default
  0xFF31) and report ID (CONFIG_ZMK_HID_VKEY_REPORT_ID, default 0x20);
• a &vkey <id> behavior that sets the selector to <id> and sends the report
  on press, and sets it to 0 and sends on release.

When disabled (the default) the report descriptor, report state, send path and
behavior are all compiled out — the firmware is byte-identical to a build
without the option.

Why

Some setups want to send "original" key codes that are guaranteed never to
collide with any standard keyboard/consumer/mouse usage, and have a host-side
agent map them to actions (launch apps, window management, IME toggles, …).
Today that needs either reusing function-row/consumer codes (which collide with
real shortcuts) or an out-of-tree patch. A vendor-defined selector report is the
HID-correct way to carry such codes: the host sees a distinct vendor collection
it can match exclusively, and normal typing is untouched because the codes live
on a vendor page no application reads.

How

• Descriptor (hid.h): under #if IS_ENABLED(CONFIG_ZMK_HID_VKEY), append
  an independent Application collection (Report ID = CONFIG_ZMK_HID_VKEY_REPORT_ID,
  one 8-bit Data/Var/Abs field, logical 0–255) after the standard collections.
  The 16-bit vendor usage page is written as a raw long item (0x06, lo, hi)
  because HID_USAGE_PAGE() emits a 1-byte item; lo/hi are split from the
  Kconfig value at compile time.
• Report state (hid.c): struct zmk_hid_vkey_report plus
  zmk_hid_vkey_set/clear/get, all gated.
• Send path (usb_hid.c, endpoints.c): zmk_usb_hid_send_vkey_report and
  zmk_endpoint_send_vkey_report, mirroring the consumer report path, plus a
  GET_REPORT case for the new report ID. zmk_endpoint_clear_reports also
  clears + resends the selector on endpoint switch, so a held vkey can't get
  stranded on the host.
• Behavior (behavior_vkey.c + DT binding): a one-parameter behavior that
  runs on the central (where HID state and the USB endpoint live) and directly
  sets/sends the selector — it does not raise a keycode event, since the vendor
  selector isn't a KEY/CONSUMER usage.

BLE HOG send is out of scope for this PR (USB transport only). The vendor
collection still appears in the HOG report map because the descriptor is shared,
so adding a HOG send path later is purely additive.

Testing

• Built all three targets of a Cyboard Imprint (two split halves + a USB dongle
  central) with CONFIG_ZMK_HID_VKEY=y; clang-format (pre-commit) and the build
  are clean.
• Confirmed the emitted report descriptor carries the vendor collection with the
  expected bytes (Report ID 0x20, usage page 0xFF31, one 8-bit selector) in
  the dongle .elf.
• The mechanism has been running out-of-tree on that board: &vkey <id>
  press/release emits a 2-byte report [report_id, id] / [report_id, 0] over
  USB, read on macOS via IOHIDManager and mapped to actions; normal typing is
  unaffected.
• With CONFIG_ZMK_HID_VKEY=n (the default) every vkey addition sits behind
  #if IS_ENABLED(CONFIG_ZMK_HID_VKEY), so the descriptor and symbols are
  unchanged.

Open questions / feedback welcome

• Naming: vkey / &vkey / CONFIG_ZMK_HID_VKEY — open to a different name
  (e.g. vendor-key / raw-hid) if preferred.
• BLE: would maintainers want HOG send in this PR, or is a USB-first landing
  with a follow-up acceptable?
• Selector width: 1 byte (single id at a time) here; a bitmap form for
  simultaneous ids could be a later, backward-compatible extension.