Normalize machine names: drop redundant cloud prefix, normalize T-shirt sizes

For cloud-service results whose .machine value contains a memory size
(GB / GiB) or a T-shirt size (XS / S / M / L / XL / NXL etc), drop
the redundant cloud-name prefix so the dashboard groups runs by the
actual size rather than the (system, machine) tuple. The system field
on each entry already carries the cloud name; repeating it inside
.machine just bloats the X axis.

Also normalize T-shirt sizing variants to their letter form:
  Small → S, Medium → M, Large → L,
  X-Small → XS, X-Large → XL,
  2X-Small → 2XS, 2X-Large → 2XL, 3X-Large → 3XL, 4X-Large → 4XL,
  5X-Large → 5XL.

Affected systems: AlloyDB, ByteHouse, CHYT, ClickHouse Cloud
(every aws/azure/gcp tier), CrunchyBridge, Databricks, Hydra,
Snowflake, Supabase, Tablespace, Timescale Cloud, pgpro_tam.

Bare-metal hardware descriptions (CPU model + RAM, "AWS c5.metal
100GB", etc) are left unchanged — the rule applies to managed-cloud
machine labels only.

Aurora's "16acu", Hologres' "16 CU", Redshift's "ra3.4xlarge", and
SingleStore's "S2"/"S24" don't match the GB or T-shirt-size pattern
and are also left alone.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Author: alexey-milovidov

alloydb/results/20231125/gcp.128GB_tuned.json

@@ -1,7 +1,7 @@
 {
     "system": "AlloyDB",
     "date": "2023-11-25",
-    "machine": "AlloyDB: 16 vCPU 128 GB",
+    "machine": "16 vCPU 128 GB",
     "cluster_size": "serverless",
     "comment": "",
     "proprietary": "yes",

alloydb/results/20231125/gcp.64GB.json

@@ -1,7 +1,7 @@
 {
     "system": "AlloyDB",
     "date": "2023-11-25",
-    "machine": "AlloyDB: 8 vCPU 64 GB",
+    "machine": "8 vCPU 64 GB",
     "cluster_size": "serverless",
     "proprietary": "yes",
     "hardware": "cpu",

alloydb/results/20231125/gcp.64GB_tuned.json

@@ -1,7 +1,7 @@
 {
     "system": "AlloyDB (tuned)",
     "date": "2023-11-25",
-    "machine": "AlloyDB: 8 vCPU 64 GB",
+    "machine": "8 vCPU 64 GB",
     "cluster_size": "serverless",
     "proprietary": "yes",
     "hardware": "cpu",

bytehouse/results/20220716/l.json

@@ -1,7 +1,7 @@
 {
     "system": "ByteHouse",
     "date": "2022-07-16",
-    "machine": "ByteHouse: L",
+    "machine": "L",
     "proprietary": "yes",
     "hardware": "cpu",
     "tuned": "no",

bytehouse/results/20220716/m.json

@@ -1,7 +1,7 @@
 {
     "system": "ByteHouse",
     "date": "2022-07-16",
-    "machine": "ByteHouse: M",
+    "machine": "M",
     "proprietary": "yes",
     "hardware": "cpu",
     "tuned": "no",

bytehouse/results/20220716/s.json

@@ -1,7 +1,7 @@
 {
     "system": "ByteHouse",
     "date": "2022-07-16",
-    "machine": "ByteHouse: S",
+    "machine": "S",
     "proprietary": "yes",
     "hardware": "cpu",
     "tuned": "no",

bytehouse/results/20220716/xs.json

@@ -1,7 +1,7 @@
 {
     "system": "ByteHouse",
     "date": "2022-07-16",
-    "machine": "ByteHouse: XS",
+    "machine": "XS",
     "proprietary": "yes",
     "hardware": "cpu",
     "tuned": "no",

bytehouse/results/20220727/l.json

@@ -1,7 +1,7 @@
 {
     "system": "ByteHouse",
     "date": "2022-07-27",
-    "machine": "ByteHouse: L",
+    "machine": "L",
     "cluster_size": 8,
     "proprietary": "yes",
     "hardware": "cpu",

bytehouse/results/20220727/m.json

@@ -1,7 +1,7 @@
 {
     "system": "ByteHouse",
     "date": "2022-07-27",
-    "machine": "ByteHouse: M",
+    "machine": "M",
     "cluster_size": 4,
     "proprietary": "yes",
     "hardware": "cpu",

bytehouse/results/20220727/s.json

@@ -1,7 +1,7 @@
 {
     "system": "ByteHouse",
     "date": "2022-07-27",
-    "machine": "ByteHouse: S",
+    "machine": "S",
     "cluster_size": 2,
     "proprietary": "yes",
     "hardware": "cpu",