[FEATURE] Reserve a non-banish free run for olfacting crates

[Shiverwarp]

Is your feature request related to a problem? Please describe. Currently it is possible to reach the crate olfaction portion and not have any free runs remaining, so we will use a louder than bomb (or other free runs that also banish) This can cost meat (in the form of buying divine champagne poppers or louder than bombs) and efficiency (we've banished a copy that we want to have in the zone for replacers)

Describe the solution you'd like We reserve a free run so that it isn't consumed by free kill or free run fights, so that it can be used during our crate olfactions

Describe alternatives and complications This will be somewhat similar to the current implementation of the freeBunnyBanishfor greg fights. Will want to pay attention to the different ways we get our free run sources (tryFindFreeRun)

Additional context Ideally we could create a manager for our banish and free run usage to assign based on highest value tasks they could be used for

[horrible-little-slime]

This will be easier when we finally move past the libram ActionSource paradigm, which has not aged great with Grimoire and iirc doesn't expose which sources are runs vs banishes.

Which is great news! Because we do need to do that!

The bad news is that we need to develop that infrastructure. If you're interested in taking that on yourself, I'd look at how the wandererManager or whatever the hell we're calling it fits in with grimoire tasks. The caching is a little arcane, but it's helpful to make sure that successive calls to our wander functions don't start returning different values when executing the same task.

Another system would be to attach whatever system you want to use for free runs and kills and banishes to the engine itself. You would override/modify the createOutfit, setCombat (I have no idea how this one works), acquireItems, and a few other methods.

[horrible-little-slime]

Oh, we could attach a value to the tasks associated with the uses of these runs, and override Engine.prototype.getNextTask to do a find on a sorted shallow copy, or do a filter and maxBy (which is probably better). Would be neat!

[horrible-little-slime]

This also feels like a strict superset and expansion of #1189 , which is a good thing. Gonna go ahead and close that as devoured by this.