fix: rds deploy crash

[oddgrd]

Description of change

We were incorrectly assuming the state to be running in the logs received from a deployment, but they could also be loading (and they will be loading for a while in the case of rds). This lead to the client reporting that the deployment crashed since it received the running state in the logs stream, but the deployment was still loading (an unexpected state since we received running in logs).

Closes #1029

TODO:

• We're not getting the logs from runtime during loading, although I think we used to (I remember seeing the "deploying <db_type>, this could take a while..." output). 🤔 This means we get "loading service" from the deployer run function, and then nothing until loading is complete.
• Should we use rwlock for the logger state? Does it matter?

How has this been tested? (if applicable)

Tested by deploying tide rds example to unstable, as well as some other examples (axum hello world, poem postgres).

[iulianbarbu]

LGTM @oddgrd ! This is a great fix.

[iulianbarbu]

Related to the TODOs:

1. The missing logs sound like a regression, but I don't see why runtime logs are not sent to the deployer. I would double-check this separately though (seems like this PR doesn't depend on the load phase logs at least).
2. I think the RW lock is the safest choice, but I also think we can use the Mutex as well for now. I don't see how the runtime can have contention read/write-wise on the logger, to make the use of Mutex inefficient. In case that might happen (by having multiple runtime tasks doing >= INFO level logging) then the RW lock would help.