Opening a compare editor blocks the UI and reads the input contents repeatedly

Opening a compare editor (for example from the Git History or Git Staging view) takes long, even for small files. The same applies to the new unified diff display.

Tracing the open path in org.eclipse.compare shows the delay is structural, not in the diff algorithm (see also #2575, where a DocLineComparator micro-optimization did not help):

- The input contents are read repeatedly during a single open. A new counting test measures 15 `getContents()` calls per side for one editor open. With EGit inputs each call re-inflates the blob since `StorageTypedElement` only buffers the storage handle.
- After the "Comparing..." job, everything else runs on the UI thread inside `createContents`. Timing tests confirm time-to-text equals time-to-diff, so nothing is visible until the diff completes (about 190 ms for 5000 lines with 100 changes, about 310 ms for 50000 lines, measured on Linux/Xvfb).
- With the unified diff preference enabled, `CompareUIPlugin.canShowInUnifiedDiff` runs the full `prepareInput` synchronously on the UI thread with a `NullProgressMonitor`, builds a throwaway `TextMergeViewer` on an invisible `Shell`, and `UnifiedDiffManager.open` then computes a second diff inline on the UI thread.

I plan to address this incrementally: measurable tests first (deterministic call counters plus repeated-run timing medians, since the old `org.eclipse.test.performance`-based tests assert nothing without the performance database), then removing the redundant lookups and reads, then moving the unified path onto the same background-job pattern as the classic editor, and finally making the initial diff asynchronous so the text shows immediately.

See also #121 for a related problem after the compare editor opens.

Start by tracing the compare-editor open path in org.eclipse.compare, including StorageTypedElement, CompareUIPlugin.canShowInUnifiedDiff, and UnifiedDiffManager.open. Run the counting and timing tests described in the issue first. Done means the measurements cover repeated reads and UI blocking, redundant work is removed, and unified and initial diff processing follow the intended background-job pattern.

Written by the indexing model from the issue text.