api: CPU placement policy, topology reporting and structured error codes

[rucoder]

Adds the API surface for SMT/NUMA-aware CPU placement of edge applications: the
controller states what a workload needs, and the device reports what it can do
and what it did.

Draft for API review. The device-side implementation lives in
lf-edge/eve#6335 and is currently built against this branch through a
replace directive. Nothing here is final; field numbers in particular are
whatever came out of writing the messages, and are free to move.

Config: what a workload asks for (config/vm.proto)

Seven new VmConfig fields, named after the Kubernetes CPUManager and Topology
Manager concepts they mirror, so a controller that already speaks Kubernetes has
no new vocabulary to learn:

• cpu_policy — shared or dedicated. Dedicated is self-sufficient: it
  implies the legacy pin_cpu flag, which stays honoured on its own for older
  controllers.
• full_pcpus_only — allocate in whole physical cores, so no other workload
  runs on a sibling thread of a core this one owns.
• threads_per_core — how many SMT siblings of each owned core become vCPUs.
  2 exposes both; 1 parks the sibling, which the workload still consumes: a
  neighbour placed there would evict its cache lines and contend for its
  execution units, which is the whole point of asking for a whole core.
• numa_policy — none, best_effort, restricted, single_numa_node.
• io_placement — whether the emulator/IO threads stay on the workload's own
  cores or are kept off them.
• isolation_tier — the strength of isolation the workload needs, as intent
  rather than as a set of mechanisms.
• disruption_policy — whether a node-level action may take the workload down.

The zero value of every field means "no preference", so a controller that sets
none of them gets exactly today's behaviour.

Info: what the node can do, and what it did

• info/hardware.proto — CPU entries carry their real topology coordinates
  (socket, physical core, NUMA node, L3 domain) and frequencies; cache domains
  report which CPUs share them; PCI devices report their NUMA node and local
  CPUs. NodeCapabilities states the node's granular abilities rather than a
  precomputed tier, so tiers are derived from capabilities instead of being
  hardcoded on the device.
• info/info.proto — ZInfoDevice.cpu_pools reports per-pool CPU utilization
  (housekeeping, dedicated, isolated) with both CPU sets and whole-core counts,
  which is what lets a controller answer "will this fit?" before a deploy and
  explain a shortage after one. API_CAPABILITY_CPU_PLACEMENT_POLICY is the
  gate a controller uses to know the device honours the config fields at all.
• info/common.proto — ErrorInfo.error_code carries a stable, machine-readable
  code alongside the existing free text, so a controller can distinguish a
  shortage a repack would fix from one nothing would fix, and from a request that
  can never be satisfied, without pattern-matching prose.

Open questions for the controller team

1. restricted and single_numa_node are currently the same thing on the
   device. They differ in Kubernetes only by how many other aligned resources
   are weighed, and CPU placement weighs none yet; they are kept distinct in the
   API so the distinction can become real once NUMA-aware placement of PCI
   devices lands.
2. isolation_tier: hard and disruption_policy: protect are refused by the
   device today rather than accepted and quietly not enforced. A controller
   should treat them as not-yet-available.
3. Unknown enum values are treated by the device as "no preference". That is only
   safe because the controller is expected to gate on api_capability — if you
   would rather have the device reject unknown values, say so.