Add tags/labels support for compute VMs

VMs have no way to attach arbitrary metadata today — the VM resource (create/get/list) only exposes id, name, state, location, boot_image, size, storage_size_gib, ip4/ip6, unix_user, firewalls, private_ipv4/private_ipv6, subnet, and gpu. No tags, no labels, and no creation timestamp either, so there's also no way to compute a VM's age after the fact.

This is a real gap for anyone provisioning VMs programmatically rather than clicking through the console. Our concrete case: a small service that spins up short-lived VM fleets on demand for batch workloads (one fleet per job), and needs to (1) group a fleet's VMs so it can tear them all down together, and (2) run a periodic sweep that kills any fleet whose owning job crashed before cleanup — a safety net against leaking billable VMs. Without tags or a creation timestamp on the VM resource itself, there's no way to do either by querying the API — the only workaround is encoding an owner id and an expiry into the VM name string and parsing it back out on every list call, which works but is exactly the kind of thing a resource with real tags wouldn't need.

This isn't a new pattern for this codebase — Postgres databases already have real tags (PostgresTag, filterable via the tags query param on listPostgresDatabases), and billing_record picked up an arbitrary jsonb tags column with dataset helpers for exactly this kind of querying (#5015, #5024). Bringing VMs to parity with what Postgres resources already have would close this gap without introducing a new pattern:

• tags (array of {key, value}, matching PostgresTag) on VM create/patch, same shape as Postgres.
• A tags filter on GET /project/{project_id}/vm and GET /project/{project_id}/location/{location}/vm, matching listPostgresDatabases.

A created_at timestamp on the VM resource would independently help the age-based cleanup case above even without tags, if that's a smaller change than full tagging support. (I noticed VmStats already computes active_age_ms internally per #5061 — but that's on the stats/ telemetry path, not the VM resource itself, so it doesn't help API consumers who just want to list VMs and see how old each one is.)

Happy to help test this against a real use case if useful.