Fix duplicate-key crash on BBCode IsBold font resolution (#3530)

[kaltinril]

Fixes #3530.

Problem

Assigning a TextRuntime.Text containing a BBCode [IsBold=true] run could crash with System.ArgumentException: An item with the same key has already been added for the bold font's FontCache .fnt key. Hit by a shipping FlatRedBall game on a wave-complete message — the "crashes on 2nd load" symptom.

Root cause

The inline-BBCode font resolver (CustomSetPropertyOnRenderable.GetAndCreateFontIfNecessary) resolves the same font once per open/close tag and dedups via LoaderManager.GetDisposable(...) as BitmapFont. That dedup is unsound: GetDisposable returns null both when the key is absent and when the key is present but holds null — it cannot tell them apart.

The BBCode path caches whatever it resolves under the font key, including its last-resort Text.DefaultBitmapFont fallback. When that fallback is itself null — as under FRB, where Gum's default bitmap font is never assigned — the first resolution caches a null under the bold key. The next resolution sees GetDisposable(...) as BitmapFont == null, treats the occupied slot as empty, falls through, and calls AddDisposable, which defaulted to ExistingContentBehavior.ThrowException and threw on the already-present key. (A non-null cached font — including a non-null DefaultBitmapFont — is recovered by the cast and never triggers this; only a cached null poisons the slot.)

The non-BBCode MonoGame path sidesteps this by never caching the fallback — it applies ?? Text.DefaultBitmapFont transiently without caching. The inline-BBCode path was the one spot that cached the fallback and then re-added under the same key unguarded.

Fix

Pass ExistingContentBehavior.Replace at both AddDisposable calls in GetAndCreateFontIfNecessary, so a re-resolution heals the occupied slot instead of crashing. Replace (rather than Dispose-then-add) is required because the occupying value can be null or the shared default font, neither of which LoaderManager.Dispose can safely handle.

Tests

MonoGameGum.Tests/Runtimes/TextRuntimeBbCodeFontCachingRegressionTests.cs poisons the exact bold cache key so the dedup guard sees an empty slot, then asserts a [IsBold=true] Text assignment no longer throws and that the slot is actually replaced with a BitmapFont (so the test can't pass vacuously if the computed key ever drifts). Two tests cover the two AddDisposable sites the fix touches: the disk/DefaultBitmapFont fallback (the crash's exact line) and in-memory font creation. Each was confirmed to fail for the right reason (the duplicate-key ArgumentException) by reverting its fix line independently; the full MonoGameGum.Tests suite is green.