Avoid overeager garbage collection

[philippjfr]

As part of #6502 I discovered that we still run garbage collection whenever a session is destroyed. Previously we had set up scheduled tasks to run garbage collection AFTER a session is destroyed ensuring that if multiple sessions are closed in succession we only run the task once. In this PR we do two things:

1. Replace the _on_session_destroyed handler on DocumentLifecycleHandler overriding the default handler which runs garbage collection
2. Add debouncing to the Document.destroy garbage collection task so it runs 5 seconds after the last session was destroyed, i.e. if multiple sessions are destroyed in quick succession we only run the garbage collection cycle 5 seconds after the last session is destroyed.

[codecov]

Codecov Report

Attention: Patch coverage is 59.45946% with 15 lines in your changes are missing coverage. Please review.

Project coverage is 82.92%. Comparing base (ddedd8d) to head (31f7ff6).
Report is 3 commits behind head on main.

Files	Patch %	Lines
panel/io/document.py	47.82%	12 Missing ⚠️
panel/io/application.py	78.57%	3 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #6518      +/-   ##
==========================================
- Coverage   82.93%   82.92%   -0.02%     
==========================================
  Files         313      313              
  Lines       45864    45902      +38     
==========================================
+ Hits        38039    38063      +24     
- Misses       7825     7839      +14     

Flag	Coverage Δ
ui-tests	40.11% <45.94%> (+<0.01%)	⬆️
unitexamples-tests	71.13% <59.45%> (-0.02%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[pankajp]

We can set _panel_last_cleanup here so that if a session is destroyed say every 4 seconds (maybe some automated polling script), then we don't end up never running cleanup!

That would also mean the first session destroyed will cause very quick gc but any immediately following session destruction will only call gc at 5s intervals.