Beam Project command needs to be split apart

[cdhanna]

these commands don't always have common intuition.

add-unreal-project <path>                  Add a unreal project to this beamable cli project
 add-unity-project <path>                   Add a unity project to this beamable cli project
update-unity-beam-package <path>           Updates or adds Beamable packages to Unity project
 generate-ignore-file <Git|P4|SVN>          Generate an ignore file in .beamable folder for given 
                                             VCS

The word "project" doesn't imply "microservices with dotnet" The word "services" doesn't imply "docker management specifically"

---

Step 1 should be to plan out all of the command suite in a single written document. One person should do this. Step 2 is to have that doc get shared and battled over.

[allister-beamable]

One thing that would be nice to consider: remixability.

I care less about the rules by which things are organized than that they are organized in a way that can be learned and applied as a pattern. In addition, if I can take that well-known pattern and add my own flair to it with scripting and aliases, that is the best of all worlds.

For example, I like the way Git does it with aliases. I can add a short alias ci (means "checkin" in my mind) to mean commit -a to add and commit in one short command. This might be meaningless, or even undesirable, for others, but Git makes it easy for me to fine-tune things for myself and support my preference for extremely short commands. We should enable users of Beam-CLI to do that for themselves.

[allister-beamable]

I still want to write a doc about logical splits for the command set, but I am not totally sure when I will be able to get to that.

Musing out loud, some principles I want to uphold:

• for me personally, the main thing I want Beam-CLI to do is handle all of the stuff that I personally cannot do easily with a text editor or a small script; for me, this mainly means marshaling the data for API calls that need more than dead-simple Postman or HTTPie commands
• generally, we should support as many developer personae as possible while still keeping the "map of the territory" as simple as possible. My persona is "cranky old keyboard warrior Linux grognard" but we ought to support ".NET power user" and "lives in the IDE" and "I don't care, just DWIM" personae as well
• duplication bad, aliasing good
• need more clarity about local manipulation (starting processes, generating .csproj files, monitoring local Docker, etc.) versus remote manipulation (publishing C#MS to Beamo, querying Beamo, pulling Beamable Content, etc.)