Expose idleListener as a method or property for toggling automatic render

Currently `idleListener` is a `protected` property, so markerclusterer instances _always_ call `render()` on map `idle` events whenever attached to a map. However sometimes this behavior isn't desirable. With large datasets rendering can take significant resources so users may wish to debounce this event or otherwise only call `render()` at their convenience. Rendering may also be pointless if the application is always going to change the marker data based on the new map location anyway, which is my current use case.

**Describe the solution you'd like**
Export a method to toggle automatic calls to `render()` by `remove()`ing or reinstating the MapEventListener at idleListener, or export a property which the body of idleListener uses to determine whether to abort before calling render().

I'm willing to make a pull request for this. see: (https://github.com/TheAtomicOption/js-markerclusterer/commit/7e1a90706274bfa731d75413df84169b3bac465f) as a first draft.

**Describe alternatives you've considered
Additionally/alternatively add a `MarkerClustererOptions` value to configure whether idleListener is assigned. This would at least allow it to be set on initialization, but users would have to write and manage their own listeners for calling render() rather than just calling a method to swap behavior.

**Additional Context**
My particular use case involves retrieving a new marker list whenever the map pans or zooms. I'm using this module along with the rest of google maps through a wrapper for Blazor, called BlazorGoogleMaps (https://github.com/rungwiroon/BlazorGoogleMaps). Unfortunately this means that there is some lag between the between the business logic and JS. Because of that, alternatives like destroying the current instance of markerclusterer on map events before idle and instantiating a new one with the new data afterwards is difficult to work around. They can easily result in race conditions when things like calls to render from the idleListener can happen before my business logic has had time to respond.

The mediocre workaround I am currently using is to set a listener on the bounds_changed map event to call `clusterer.clearMarkers(true)` which at least avoids rendering the current set of markers until the next set of markers are added. But it's not optimal since I have to pass the entire marker set back into markerclusterer rather than being able to update it addMarkers()/removeMarkers()