fix rw deploy render redundant api processes causing server to exceed mem limit

[thedavidprice]

fixes #4271

TODO:

• Release Notes: add 1.0.0 deprecation notice for rw-api-server binary; use rw-server api instead

Render Deploy API Server < 500MB Mem

Now uses imports from the api-server package to programatically start fastify without spawning or running another RW CLI command (which was the root cause of multiple running processes). Total process mem < 225MB.
run yarn rw deploy render api

process memory

Additionally I cleaned up a few things with the setup deploy render and deploy render commands.

api-server console output

The console outputs for apiServerHandler, webServerHandler, bothServerHandler weren't consitent and didn't always make sense to me. I've updated them accordingly:

bothServerHandler aka yarn rw serve

apiServerHandler aka yarn rw serve api

webServerHandler aka yarn rw serve web

New api-server bin in `package/api-server/package.json

Previously the serve api process could be run via bin, e.g. yarn rw-api-server. It made sense to me to add a bin that would handle running api, web, or both.

This is now possible via yarn rw-server:

• Sides: defaults to both, takes api or web
• Options: take the api-server options for api (port, socket, apiRootPath), web (port, socket, apiHost), or both (port, socket)

[thedavidprice]

This is close. Having an issue with Yargs (specific to deploy render command) that's been challenging to diagnose.

Ready 🚀

[Tobbe]

Nice work @thedavidprice! Can't wait to take this for a spin on my own Render deploy!

[crcastle]

Awesome work @thedavidprice! I may not have time to check it out this weekend, but I will on Monday or Tuesday for sure. cc @SEANDOUGHTY

[dac09]

LGTM! Just have to merge and take it for a spin

[thedavidprice]

re:

either way, we should update the setup deploy render to set apiUrl to "/" to be consistent (logically) with the API path during production deploy. (Again, I understand it's not applicable mechanically. But in all other cases we update to match what the deploy host provider is going to use for the API path — so I'm just suggesting consistent behavior.)

I'm unable to do this due to this bug #4352

Skipping so I can get this in.