As seen by this kind of crash, having the `.ToMod` method throw can be
very problematic and also hidden (as it is used inside of models in
places where exceptions are not expected to occur).
Given there are tens of usages of this method, returning a placeholder
mod seems like a better idea than outright throwing.
```
An unhandled has occurred.
System.InvalidOperationException:
There is no mod in the ruleset (osu) matching the acronym AS.
at osu.Game.Online.API.APIMod.ToMod(Ruleset ruleset) in /Users/dean/Projects/osu/osu.Game/Online/API/APIMod.cs:line 54
at osu.Game.Scoring.ScoreInfo.<get_Mods>b__117_0(APIMod m) in /Users/dean/Projects/osu/osu.Game/Scoring/ScoreInfo.cs:line 193
at System.Linq.Enumerable.SelectArrayIterator`2.ToArray()
at osu.Game.Scoring.ScoreInfo.get_Mods() in /Users/dean/Projects/osu/osu.Game/Scoring/ScoreInfo.cs:line 193
at osu.Game.Screens.Select.Leaderboards.BeatmapLeaderboard.<>c.<subscribeToLocalScores>b__40_2(ScoreInfo s) in /Users/dean/Projects/osu/osu.Game/Screens/Select/Leaderboards/BeatmapLeaderboard.cs:line 199
at System.Linq.Enumerable.WhereEnumerableIterator`1.MoveNext()
at osu.Game.Database.RealmObjectExtensions.Detach[T](IEnumerable`1 items) in /Users/dean/Projects/osu/osu.Game/Database/RealmObjectExtensions.cs:line 180
at osu.Game.Screens.Select.Leaderboards.BeatmapLeaderboard.<>c__DisplayClass40_0.<subscribeToLocalScores>g__localScoresChanged|1(IRealmCollection`1 sender, ChangeSet changes, Exception exception) in /Users/dean/Projects/osu/osu.Game/Screens/Select/Leaderboards/BeatmapLeaderboard.cs:line
209
at Realms.RealmCollectionBase`1.Realms.INotifiable<Realms.NotifiableObjectHandleBase.CollectionChangeSet>.NotifyCallbacks(Nullable`1 changes, Nullable`1 exception)
at Realms.NotifiableObjectHandleBase.NotifyObjectChanged(IntPtr managedHandle, IntPtr changes, IntPtr exception)
```
One of my pending work items for post-realm merge.
The lowest-level import task is no longer asynchronous, as we don't want
it to span multiple threads to allow easier interaction with realm.
Removing the `Task` spec simplifies a heap of usages.
Individual usages should decide whether they want to run the import
asynchronously, by either using an alternative override or spooling up a
thread themselves.
