Support dynamic instance counters in dotnet-counters monitoring

## Background and Motivation

In a few of my projects I use counters that are 'instanced', that is a set of unique counters is created per-instance of an object (e.g. per connection, per session, etc). The lifetime of these instance counters is bound to the instance (being created on construction and disposed with the instance), and each counter has a unique name.

For example, I have an FPS counter for each video camera connection, which have names such as "1_FPS", "2_FPS", etc. These connections start and stop over time, with an ever-growing number of counters being seen, but only 2 or 3 active at any one time. The counters are disposed when the connections are disposed. An alternative would have been to have them as a static counter, with unique payloads identifying the instance, but the current tooling would not make it easy to visualise the separate instances.

The problem is that `dotnet-counters` assumes a static list of counters that only grows. Once a counter is 'seen' it is never removed. Eventually, this leads to an unmanageable list of counters on display, when monitoring, and currently (#1716), will cause a crash.

## Proposed Feature

When a counter is disposed it should be removed from display. I can't see where an `EventListener` can detect the disposal of an `EventSource` (this seems like an oversight in the design), which is a shame as automatic detection of disposal would be preferable. However, as far as the monitor is concerned that isn't the most important as I propose we rely on a timeout method anyway. A timeout would also cover the scenario of short-lived event sources, ensuring they are displayed for long enough to be noticed.

I propose we add an `eventSourceTimeout` parameter (in seconds) to `dotnet-counters` which will remove an event source from display after not receiving any further updates for the specified period. This should probably default to something sensible like `60`, with a value of `0` disabling the feature (current implementation).

## Usage Examples

In most use cases the default value of `60`s would not cause any noticeable impact, as most counters update every second. Where consumers have instance counters that are changing relatively quickly, they could reduce this value to `2`s to ensure the display does not become cluttered, e.g:

`dotnet-counters monitor -n MyApp --eventSourceTimeout 2 --providers System.Runtime MyInstanceCounters`