Introduce a way to debug relayouts and slow measures/layout

This cl introduces a way to debug 2 different but related things:

(1) Which classes suffer from long measure and layout pass
(2) What caused those classes to be re-measured/re-layout

In the current form, only sysui sets the flags to enable the above based on some sysprop.

(1) is enabled by `adb shell setprop persist.debug.trace_layouts 1` for all classes in sysui process (note: the process needs to restart). The ideal workflow is to first enable this to spot which are the main classes have long measure/layout slices. Once those are identified (e.g. class X)

(2) `adb shell setprop persist.debug.trace_request_layout_class X` enables requestLayout tracing for class X. At this point, every time requestLayout is called on that class, both an instant event (visible in perfetto) and the stacktrace (in logcat) is output.

After recording at perfetto trace with (2) enabled, it's possible to aggregate data with an SQL query in ui.perfetto.dev: For example, with the following we can have the most common relayout reasons:
```
SELECT count(*) cnt, msg
FROM android_logs
WHERE msg LIKE "requestLayout %"
GROUP BY msg
ORDER BY cnt DESC
```

The following helper bash function makes the above more efficient:

trace_class_layouts() {
        adb shell setprop persist.debug.trace_layouts 1
        adb shell setprop persist.debug.trace_request_layout_class $1

        adb shell am force-stop com.google.android.apps.nexuslauncher
        adb shell am force-stop com.android.systemui
}

Then, use `trace_class_layouts X` and record a perfetto trace.

To reduce the overhead, several strings are cached when the view is attached to the window. However, it should be noted that enabling this can have an impact on performance and should only be used for debugging purposes.

Test: record a trace after enabling options
Bug: 266090955
Change-Id: I89a518d4f3c69c13cdced0f70d8a1e2793bc923a