`spacetime start` allows restricting who can create new databases

Objective

In an effort to improve the self-hosting user experience we need to be able to restrict publishing to only certain identities. Ideally the UX would look like this:

spacetime start -l 0.0.0.0:3000 \
    --publish="restricted"
    --publish-allow-list "\
c20093cd8df79879ae6d2b058650ca5112d6bb11334b5003f443cc0776da3d15,\
c20093cd824532bc5748afb2648f236de3164546275271823452354234f2f2f2,
c20093cd8df79879ae6d2bc058650ca5112d6bb11334b5003f443cc0776da3d5,"

This adds 2 new arguments to start:
--publish

• Can either be set to open or restricted. The default is open.

--publish-allow-list

• This is a comma-separated list of SpacetimeDB identities that are allowed to create new databases. This does not allow you to publish to any database it only gives you the ability to create new databases.

Rationale

A huge part of why many users use SpacetimeDB is the user experience, and the current self-hosting user experience is quite bad.

Right now our documentation shows users how to install SpacetimeDB + nginx and gives them the option to block all routes except for the /v1/<database>/subscribe route for remote clients. The problem with this is then they are not able to publish remotely. There are 2 solutions to this:

1. We tell the users that they have to upload their module to the remote host via sftp and then publish locally. This is a super clunky user experience. You also need to install all of the dependencies for building your module on the remote machine (including dotnet/cargo, etc.).
2. We could tell them what we do with BitCraft which is restricting publish to only tailscale but this requires everyone who follows the guide to use tailscale which is also sub-optimal. I also do not want this guide to have a dependency on tailscale in order to be considered "secure".

I would like to be able to change the guide to not use tailscale and not block custom routes via nginx so that the documentation is a lot simpler and the user experience is what I would consider "optimal" which means users can just publish to their self-hosted instance like any other server.

Start at the spacetime start command entry point and trace how publishing and new database creation are currently authorized. Done means the two options accept the stated values, preserve the open default, restrict only new database creation to the allow-list, and have corresponding verification.