Fix data race in MigraDoc FontHandler's single-entry font cache

[tgburgin]

Fixes #381.

FontHandler.FontToXFont memoises the last (Font, XFont) pair in two independent statics written without synchronisation, so a reader can confirm _lastFont is its own Font and then read an _lastXFont that another thread has already replaced. The method then returns an XFont belonging to a different Font, usually at a different size. Nothing throws — the document is silently typeset wrong, on measurement (wrong widths, wrong wrapping) or on drawing (a Tf at the wrong size mid-line). #381 has the full interleaving, the reproduction and the measurements.

The change

Both references are now assigned in the constructor of one immutable FontCacheEntry and published by a single reference assignment to a volatile field. A reader takes one snapshot of that field, so it sees either the complete previous entry or the complete new one — never the Font from one and the XFont from another.

var entry = _lastEntry;
if (entry != null &&
    entry.FontRef.TryGetTarget(out var lastFont) && font == lastFont &&
    entry.XFontRef.TryGetTarget(out var lastXFont))
    return lastXFont;

One file, no public API change.

Why not a lock

The fast path stays lock-free, which matters because this is on every layout and every draw. volatile costs nothing on x64 reads. A Monitor would also work — and Locks.EnterFontManagement() already exists next door in PdfSharp.Internal.Threading — but it would put a lock acquisition on the hottest path in the renderer for no benefit over an atomic publish.

Preserved deliberately

• Single-entry cache. Not widened to a dictionary — that is a different decision with different memory behaviour, and this PR is a correctness fix.
• WeakReference semantics, including the FORCE_MEMORYLEAK conditional, exactly as they were.
• Allocation count. A miss allocated two WeakReferences before; it now allocates two plus one small entry object, only on a miss. A hit allocates nothing, as before.

Verification

Isolating the cache shape and hammering both versions with two equally-hot keys, 8 threads, .NET 10 / Windows x64:

	tears / 400,000
two independent statics (current)	104,457
single published entry (this PR)	0

Against the real FontToXFont by reflection with two stable Font instances at 9 pt and 6.5 pt, 8 threads × 200,000 calls, the current code tears in both directions — asked 6.5pt, returned 9pt and asked 9pt, returned 6.5pt. (Fewer absolute tears there only because XFont construction dominates the loop.)

No test added

A test for this is inherently probabilistic — the window is a few instructions wide — and I did not want to introduce a flaky test into your suite. The reproduction in #381 is self-contained if you would like one, and I am happy to add it in whatever form you prefer.