Update Bee API methods to go directly through executionInfo

[Hamms]

Rather than calling a subtype method which THEN queues an action which
then calls a subtype method, this PR untwitsts things to make the flow
of execution more linear.

Okay, so Subtypes that support Quantum maps need to provide two versions of their major methods:

1. A "headless" version that doesn't care about animation but will call executionInfo.terminateWithValue if it can't complete successfully. This is used for the validation of the Quantum maps to see if the user's code passes.
2. An "animation" version that does care about animation (and audio) but doesn't need to care about validation. This is used to animate the execution of the user's code after we've already validated it with the headless version.

We have so far been calling those methods like this:

• Make an API call
  • API call calls the subtype headless method
    • subtype headless method does its validation and, if the validation passes, uses executionInfo.queueAction to queue up the animation method

But this means that subtypes need to know about execution info and action queuing. I instead propose we change our expectations to add a requirement that the headless version will return a boolean representing whether or not the validation passed. We can then:

• Make an API call
  • API call calls the subtype headless method
  • API call conditionally queues up the animation method based on the result of the headless method

This means that subtypes no longer need to know about action queuing, and just need to know enough about executionInfo to be able to terminate if something goes wrong.

Then, in a future PR, I can refactor that away, too, and subtypes will no longer need to have any concept of a user's code being executed.

[Hamms]

PTAL

[balderdash]

I like it.

[balderdash]

Maybe this should be tryGetNectar, just so it's more clear that it attempts to get nectar?

Perhaps that would change back when you pull the termination value out of the subtype, so I'll leave it up to you.

[Hamms]

hmm, maybe I should update the comment.

It not only attempts to get nectar, but also does so if it can, via this line.

The way the maze code execution works (which is probably a bit more complicated than it needs to be) is that is makes all the api calls which as a side effect runs all the headless stuff, then resets the environment and runs the queued animation actions.

[balderdash]

That's the behavior I'd expect from a tryFoo method (i.e. actually do foo, or return false if foo would throw/actually does throw an exception), but I suppose that expectation is not as universal as I had thought.

I think the comment is fine as is.