Add rojo open

[nezuo]

Closes #305.

• Support existing local places (partially-managed).
• Potentially support cloud places (except for automatically connecting)
• Potentially installing the rojo plugin locally
• Rojo saves previous hosts/ports you've connected to. When we generate a port, we don't want that to be saved.

[nezuo]

My current thoughts on the API:

rojo open <PROJECT_FILE>

Flags:
--output (-o) <PATH>: Builds the place from scratch and output it at <PATH>.
--place (-p) <PATH_OR_CLOUD_PLACE_ID>: Opens an existing place, doesn't build anything from scratch and doesn't skip the initial sync.

--output and --place can't both be specified.

I also want a flag to skip initial sync even with --place. I have projects that are fully managed but part of the build step uses Lune. This means I have existing place files that I can't build from scratch with Rojo but I still want to skip the initial sync. I'm worried that this flag might introduce confusion for users and I don't know what to call it.

Thoughts?

[nezuo]

One flaw with injecting a StringValue is that if the user opens an existing place and doesn't save it, the next time they open it the StringValue will still be there.

Maybe existing places shouldn't automatically connect? That would be really unfortunate.

[Yumacide]

Rojo saves previous hosts/ports you've connected to. When we generate a port, we don't want that to be saved.

It might be better not to randomize the port then. The behavior shouldn't be different from rojo serve.

[iminlikewithyou]

is the idea of this command to be exactly like serve, except you also specify one of..?:

• an output to build to
• a place file to use
• a Roblox place ID

[nezuo]

Yes, the ideal version would support local places, cloud places, partially-managed, fully-managed. On top of that, it also automatically syncs with the studio plugin. It can also skip the initial sync if it's a fully-managed project that was just built.