Dashboard metrics widget (connected users / load times / memory use)

### Description

The v1 dashboard is 'ugly' to get system type metrics out of.

I have found that the bear minimum metrics would be number of connected humans, dashboard load time and Node-RED memory use.

First up, any large dashboard needs to be run with the `--max-old-space-size=8192` (https://discourse.nodered.org/t/out-of-memory-crash-on-windows-10-pc/54141/22?u=thebaldgeek) start up command. Must. Not optional.

Next up, make changes to settings.js (https://discourse.nodered.org/t/out-of-memory-crash-on-windows-10-pc/54141/4?u=thebaldgeek) so that heap and memory use can be seen at start up.

Make heavy use of browser developer tools (https://discourse.nodered.org/t/how-to-make-dashboard-webserver-more-robust/61295/26?u=thebaldgeek)
Extensive time with Google is required to dig into the parts loaded by the dashboard so long load items can be identified and tweaked (or usually given up on and simply removed) for faster response.

Then use extensive wrangling with the ui_control node to try and measure user clicks etc to track the number of connected users vs Cloudflare cache IP addresses. (Using geo-ip API to try and find 'cloudflare' in the IP address return to remove those from 'tracking' so knowledge of actual number of connected users can be determined).

Note about Cloudflare. Since the dash is both single user and single page app, using Cloudflare cache is a real blessing and curse. Its needed so users don't trample over each other, but since since the whole site is dynamic, there is very little content that can be cached, so it does not actually help beyond helping each user to see their data for as long as needed.
Also the cache causes the editor to have little melt-downs pretty often and you lose changes unless deployed before the cache timer expires, so you end up editing and deploying 100's of almost click by click tiny changes vs making the changes you want over about 5 minutes and thus timing out the cache for the editor and losing all that work.

Lastly, its critical to make use of the exec node to pull PM2 metrics (`pm2 jlist`, then a JSON node, then pull this key:value -> `msg.payload[0].pm2_env.axm_monitor["HTTP P95 Latency"].value`)

This boils down to a 'connected user graph vs dashboard load latency' graph.

Graph of the past month showing 80 users results in upwards of 80 second load times before seeing the /ui/ v1 dashboard home page. (Graph in non-Node-RED dashboard as long graph times are a problem for me in using the v1 graph node).

I was able to use all this data over the space of a year or so to make improvements to the flows running the dashboard and thus get the load times down to the 'acceptable' value of 60 to 80 seconds and disconnects no more than about every 5 minutes. I found that people give up when its over 2 minutes to load the dashboard and frequent timeouts are the biggest turn-aways.

I propose a 'dash_metrics' widget that does a lot of this digging (and more) for the user.

Difficult things made easy.

### Properties

_No response_

### Events

_No response_

### Controls

_No response_

### Existing Examples

_No response_

### Have you provided an initial effort estimate for this issue?

I am no FlowFuse team member