Add a kind field to memory reports.

This is used for two memory reporting improvements.

- It's used to distinguish "explicit" memory reports from others. This
  mirrors the same categorization that is used in Firefox, and gives a single
  tree that's the best place to look. It replaces the "pages" tree which
  was always intended to be a temporary stand-in for "explicit".

- It's used to computed "heap-unclassified" values for both the jemalloc
  and system heaps, both of which are placed into the "explicit" tree.

Example output:
```
|  114.99 MiB -- explicit
|      52.34 MiB -- jemalloc-heap-unclassified
|      46.14 MiB -- system-heap-unclassified
|      14.95 MiB -- url(file:///home/njn/moz/servo2/../servo-static-suite/wikipe
dia/Guardians%20of%20the%20Galaxy%20(film)%20-%20Wikipedia,%20the%20free%20encyc
lopedia.html)
|          7.32 MiB -- js
|             3.07 MiB -- malloc-heap
|             3.00 MiB -- gc-heap
|                2.49 MiB -- used
|                0.34 MiB -- decommitted
|                0.09 MiB -- unused
|                0.09 MiB -- admin
|             1.25 MiB -- non-heap
|          1.36 MiB -- layout-worker-3-local-context
|          1.34 MiB -- layout-worker-0-local-context
|          1.24 MiB -- layout-worker-1-local-context
|          1.24 MiB -- layout-worker-4-local-context
|          1.16 MiB -- layout-worker-2-local-context
|          0.89 MiB -- layout-worker-5-local-context
|          0.38 MiB -- layout-task
|             0.31 MiB -- display-list
|             0.07 MiB -- local-context
|       1.56 MiB -- compositor-task
|          0.78 MiB -- surface-map
|          0.78 MiB -- layer-tree
```
The heap-unclassified values dominate the "explicit" tree because reporter
coverage is still quite poor.

components/profile_traits/mem.rs

@@ -23,12 +23,48 @@ impl ProfilerChan {
     }
 }
 
+/// The various kinds of memory measurement.
+///
+/// Here "explicit" means explicit memory allocations done by the application. It includes
+/// allocations made at the OS level (via functions such as VirtualAlloc, vm_allocate, and mmap),
+/// allocations made at the heap allocation level (via functions such as malloc, calloc, realloc,
+/// memalign, operator new, and operator new[]) and where possible, the overhead of the heap
+/// allocator itself. It excludes memory that is mapped implicitly such as code and data segments,
+/// and thread stacks. "explicit" is not guaranteed to cover every explicit allocation, but it does
+/// cover most (including the entire heap), and therefore it is the single best number to focus on
+/// when trying to reduce memory usage.
+#[derive(Deserialize, Serialize)]
+pub enum ReportKind {
+    /// A size measurement for an explicit allocation on the jemalloc heap. This should be used
+    /// for any measurements done via the `HeapSizeOf` trait.
+    ExplicitJemallocHeapSize,
+
+    /// A size measurement for an explicit allocation on the system heap. Only likely to be used
+    /// for external C or C++ libraries that don't use jemalloc.
+    ExplicitSystemHeapSize,
+
+    /// A size measurement for an explicit allocation not on the heap, e.g. via mmap().
+    ExplicitNonHeapSize,
+
+    /// A size measurement for an explicit allocation whose location is unknown or uncertain.
+    ExplicitUnknownLocationSize,
+
+    /// A size measurement for a non-explicit allocation. This kind is used for global
+    /// measurements such as "resident" and "vsize", and also for measurements that cross-cut the
+    /// measurements grouped under "explicit", e.g. by grouping those measurements in a way that's
+    /// different to how they are grouped under "explicit".
+    NonExplicitSize,
+}
+
 /// A single memory-related measurement.
 #[derive(Deserialize, Serialize)]
 pub struct Report {
     /// The identifying path for this report.
     pub path: Vec<String>,
 
+    /// The report kind.
+    pub kind: ReportKind,
+
     /// The size, in bytes.
     pub size: usize,
 }