Fix crash on drag selection via timeline while placement is active

[bdach]

This was reported in #28474, albeit the code changes proposed there did not fix the issue at all.

See 8b6385f for demonstration of the crash scenario. Basically what is happening there is:

• The starting premise is that there is a spinner placement active.
• At this time, a drag selection is started via the timeline.
• Once the drag selection finds at least one suitable object to select, it mutates SelectedItems.
  

  osu/osu.Game/Screens/Edit/Compose/Components/Timeline/TimelineBlueprintContainer.cs

  Lines 179 to 183 in 2d4121b

  	foreach (var hitObject in Beatmap.HitObjects.Except(SelectedItems).Where(shouldBeSelected))
  	{
  	Composer.Playfield.SetKeepAlive(hitObject, true);
  	SelectedItems.Add(hitObject);
  	}

• When selection changes for any reason, the HitObjectComposer decides to switch to the "select" tool, regardless of why
  the selection changed.
  

  osu/osu.Game/Rulesets/Edit/HitObjectComposer.cs

  Lines 431 to 438 in 2d4121b

  	private void selectionChanged(object sender, NotifyCollectionChangedEventArgs changedArgs)
  	{
  	if (EditorBeatmap.SelectedHitObjects.Any())
  	{
  	// ensure in selection mode if a selection is made.
  	setSelectTool();
  	}
  	}

• Changing the active tool causes the current placement - if any - to be committed, which mutates the beatmap.
  

  osu/osu.Game/Screens/Edit/Compose/Components/ComposeBlueprintContainer.cs

  Lines 390 to 407 in 2d4121b

  	/// <summary>
  	/// The current placement tool.
  	/// </summary>
  	public HitObjectCompositionTool CurrentTool
  	{
  	get => currentTool;
  	set
  	{
  	if (currentTool == value)
  	return;
  	currentTool = value;
  	// As per stable editor, when changing tools, we should forcefully commit any pending placement.
  	commitIfPlacementActive();
  	}
  	}

• Back at the drag box selection code, this causes a "collection modified when enumerating" exception.

The proposed fix here is to eagerly commit active placement - if any - when drag selection is initiated via the timeline, which avoids this issue. This also appears to vaguely match stable behaviour and is sort of consistent with the logic of committing any outstanding changes upon switching to the selection tool.

cc @Hecatia-Lapislazuli

[ppy-sentryintegration]

Sentry issue: OSU-1174