Don't spam consecutive parent suppressions in NotifLog.

Previously, we were logging parent suppressions on every build that they happened. This is not ideal, since if the state causing the suppression doesn't change for a long time, the suppression logs will be repeated many times, hogging the buffer. See related bug: b/244592922

Instead, I opted to log this suppression once when it starts happening, and a second time when it stops. This prevents the situation described above, and in the linked bug, with many duplicate lines of "Change of parent to .. suppressed".
One downside of this, however, is if the suppression only happens for a single iteration, we are now creating two log entries instead of one. This could technically be avoided if we did something a bit more complicated, e.g. tracking "in-progress" suppressions and only calling logParentSuppressedStopped for suppressions lasting longer than 1 iteration. However, this would imo add unnecessary complexity for an insignificant improvement.

Fix: 250876257

Test: Forced a suppression using Notify2-SC by posting two delayed notifications (while there was no group for this app already in the list) and opening the shade, then keeping it open for a bit. Dumped the relevant logs by calling:
```
adb shell dumpsys activity service com.android.systemui/.dump.SystemUIAuxiliaryDumpService
```
and compared the results in the NotifLog section.
Example logs before this change (notice the multiple consecutive suppression logs): go/paste/5500881658183680
Example logs after this change (only logging beginning and end of suppression): go/paste/5866408205352960

Change-Id: Ieccb7284ac5f5cc230f55d4ab5b717d19cc2000e