Incremental retrieval of plans as they are discovered

Planners that support multiple plans are penalized by this interface in the eyes of the end user. The planner may have come up with one or multiple plans, but the end-user still stares at a blanc screen.

Rather than the state transition from `PENDING` to `ok`, we should support `QUEUEING` -> `INITIALIZING` -> `SEARCHING_FOR_INITIAL_PLAN` -> `SEARCHING_FOR_INITIAL_PLAN` -> `STOPPED` -> HTTP404 (when the plans are removed).

The first endpoint post request should return the session/run ID:

`POST /package/xyz/solve`

```json
{
"status": "QUEUEING",
"id": "qwer-qwer-qwer-qwer"
}
```

`GET /package/xyz/solve/qwer-qwer-qwer-qwer`

```json
{
"status": "SEARCHING...",
"plansFound": 2
}
```

`GET /package/xyz/solve/qwer-qwer-qwer-qwer/plans/1`

```json
{
"actions": [],
"metric": 123,
"elapsedTime": 1234
}
```

Similarly, the client should have the power to stop the planning process and purged all the data:

`DELETE /package/xyz/solve/qwer-qwer-qwer-qwer/`

Note that that the URL structure does not need to repeat the `/package/xyz/solve/` prefix, but if it does not, we have to come up with a different term for it, e.g. `/request/qwer-qwer-qwer-qwer/`