fix(markdown): prevent compare editor freezes and lost refreshes

[sebthom]

Problem

Opening a Markdown comparison can freeze Eclipse when an existing compare editor replaces its input.
Disposing the old viewer disconnects its shared file buffer on the UI thread.
The Markdown buffer-disposal listener then deletes problem markers synchronously.
If another workspace operation holds the required lock, the UI waits for that operation to finish.

Two thread dumps taken about 30 seconds apart captured the same UI wait.

"main" ...
   java.lang.Thread.State: TIMED_WAITING (on object monitor)
    ...
    at org.eclipse.core.internal.jobs.OrderedLock.acquire(OrderedLock.java:87)
    at org.eclipse.core.internal.resources.WorkManager.checkIn(WorkManager.java:126)
    at org.eclipse.core.internal.resources.Workspace.prepareOperation(Workspace.java:2452)
    at org.eclipse.core.internal.resources.Resource.deleteMarkers(Resource.java:865)
    at org.eclipse.wildwebdeveloper.markdown.MarkdownDiagnosticsManager.clearMarkers(MarkdownDiagnosticsManager.java:305)
    at org.eclipse.wildwebdeveloper.markdown.MarkdownDiagnosticsManager$1.bufferDisposed(MarkdownDiagnosticsManager.java:182)
    ...
    at org.eclipse.core.internal.filebuffers.TextFileBufferManager.disconnect(TextFileBufferManager.java:213)
    ...
    at org.eclipse.compare.contentmergeviewer.TextMergeViewer.disconnect(TextMergeViewer.java:2189)
    at org.eclipse.compare.contentmergeviewer.TextMergeViewer.handleDispose(TextMergeViewer.java:2138)
    ...
    at org.eclipse.compare.internal.CompareEditor.doSetInput(CompareEditor.java:276)
    ...
    at org.eclipse.compare.CompareUI.reuseCompareEditor(CompareUI.java:207)
    ...
    at org.eclipse.egit.ui.internal.actions.CompareWithIndexActionHandler.execute(CompareWithIndexActionHandler.java:50)

Changes

• Run marker updates and close cleanup in background workspace jobs.
  A shared job group serializes this work even when the workspace supplies no marker scheduling rule.
  Buffer disposal can return without waiting for marker writes.
• Tie diagnostic requests and queued reports to the original shared-buffer instance.
  Delayed cleanup cannot erase markers from a reopened buffer, and late responses from an old session are ignored.
  A reopened buffer can start diagnostics while an old request is still pending.
• Keep duplicate suppression active until marker application completes.
  Server invalidations received during an active refresh retain one follow-up pull.
  Opportunistic parser requests remain suppressed because they can originate from the diagnostic request itself.
• Use the live document for offsets in unsaved editor content.
  For unopened files, use a private buffer manager so temporary reads do not trigger shared-buffer disposal and delete markers.