Task subclassing model

Fastly uses an `AsyncTask` model that stores on the `AsyncTask` class, the promise, and a function that will handle the process the "next steps" after the handle is ready, to then eventually resolve the promise.

On the other hand, `StarlingMonkey` only supports a singular `run` or `cancel` method on tasks.

So we have two separate task models in play:

1. Fastly's task model, based on async handles, having "next steps" which resolve a promise ala spec algorithm descriptions
2. StarlingMonkey's task model, where each subsystem subclasses their own tasks, and implements a single synchronous run function which is effectively those same "next steps", but with context and state specific to each subsystem subclass.

In adapting Fastly async tasks to this model, the easiest way to do this is to just subclass `AsyncTask` with `FastlyAsyncTask` that provides the original slots - `[[Promise]]` and `[[NextSteps]]`, and then to use that like we had before.

This works fine, but I wanted to post this issue to see if there's more context on StarlingMonkey's async model that I'm perhaps missing.

The issue names no files, tests, or entry points. Start by comparing Fastly's AsyncTask model with StarlingMonkey's run/cancel task model; work is not ready to begin until the intended subclassing approach and scope are decided. Done would require an explicitly scoped implementation and validation plan.

Written by the indexing model from the issue text.