getSnapshot() non-cached option
# Feature Request

### Description
Hey Dusty.

Due to popular demand, I've recently implemented snapshot support in ring-mqtt so that users can get snapshots either on motion events, on an interval, or both.  The default behavior for interval snapshots is to get a new snapshot ever 30 seconds, for wired cameras, or ever 10 minutes for battery camera, although users can control the interval if they really want to.  This works, well, but of course happens continuously, even if someone is not viewing, because, since I'm using MQTT, I have no way to know if snapshot images are being viewed actively or not.

The issue comes with the feature which attempts to get an updated snapshot during a motion event.  The problem is, if there happens to be a motion event within 10 seconds of the most recent interval based snapshot, ring-client-api returns the cached snapshot.  With 30 second refreshes there's a 1 in 3 chance the image returned is the cached image instead of the motion image.

I fully understand the issues around battery cameras not being able to take snapshots on while recording a motion event.  I've worked around this as best I can by grabbing a still image from the live stream for battery cameras.  However, for powered cameras, I don't think there's any issue requesting a snapshot at any time, it's just the getSnapshot() implementation that returns a cached snapshot if called within 10 seconds.  In ring-mqtt I've implemented a workaround where, if the camera has an active ding event, I just call the Ring Rest APIs directly to force a new snapshot, effectively bypassing getSnapshot().  This seems to work well and isn't difficult at all, but seems less than ideal.

### Describe the solution you'd like
I was wondering if you might consider a small change to getSnapshot() so that a new ding event immediately invalidates the snapshot cache so the next call to getSnapshot() would always return an updated image regardless of when the last snapshot was taken.  Looking at the code I think it would be fairly easy to implement (although I'm not sure as it also looks like you might just pull the latest snapshot from the API if the timestamp is less than the expire time, but you could also condition this on active ding for example).   Implemented carefully I don't believe it would open up the door for any API abuse.

### Describe alternatives you've considered
I considered calling getSnapshot() on a loop until it returns a new image, but this can sometimes lead to a significant delay in snapshot delivery and, in some cases, whatever cause the motion event is already gone by then, so it limits the functionality somewhat.  I also considered always using the livestream to grab a snapshot like I do for battery cameras, but it feels heavy handed, isn't 100% reliable (I have error checks for cases where the stream fails to start and retries) and the quality of the image is variable (I try to grab a keyframe directly from the AVC stream, but it sometimes still has motion blur, maybe I still don't have my ffmpeg options just right).