Implement "Create a new project" option

[TrCaM]

Description

Implement Create a new project option of firebase init command to actually create a new project instead of asking user to create the project with Firebase Console.

• What changes: if the default project is not set
  • Ask a selection question with 3 choices asking for user's desired behavior: Use an existing project, Create a new project and Don't set up default project
  • Use and existing project: (completed)
    • If the logged in account has at most 100 projects, list all projects and let user select project from the list
    • If the logged in account has more than 100 projects, prompt user for the project ID of the desired Firebase projects
  • In this PR Create a new project
    • Reuse the flow from projects:create command to create a new project
    • Set the new project as the default project for the current directory
  • Don't set up default project => do nothing

API methods changes

• Moved createFirebaseProject(), which implements the whole project creation flow and command line output, from commands/projects-create.ts to management/projects.ts since this process is reused in init/features/project.ts

Notes:

• This PR is implemented on top of all changes made in Re-implement firebase init command's default project setup flow #1506

TODO:

• Write unit test for createFirebaseProject() method which was moved into /management/projects.ts, once the approach is approved (Update: skipping testing since we already tested the underlying API methods)

[coveralls]

Coverage decreased (-0.1%) to 63.115% when pulling 7e4d320 on tc-init-create-project-opt into bddf9b5 on tc-choose-project.

[bkendall]

I think things generally look fine in this PR... I'd ask @mbleigh for his opinion on where that code ends up as well though.

[TrCaM]

@bkendall, @mbleigh, @nbegley. One last problem in this PR. createFirebaseProjectAndLog() is now a valid testing target. As you can remember, ora is a bit tedious to stub since the library export the function directly. A while ago I made an OraWrapper class to solve the problem, but IMO doing that just for testing is not ideal. In fact, I found proxyquire library can be a good solution if we agree to add an extra dependency to our repo

So the question is, can we just omit testing this? (I think we shouldn't). And if we decide to test, what're your opinions on testing ora?

[bkendall]

Please don't add proxyquire - I've found it ends up promoting bad design....

This is one of those difficult choices - at some point, things aren't easily testable (especially when there's user input and logging involved), so we have to put some trusts in the tests we have and the manual testing we do. The fact that the function is exported doesn't make testing a requirement, technically. We definitely should have as many tests as we can, but at some point it becomes difficult.

Design-wise, this is why we try to keep as much of that logging in the Command files - those are already very difficult to test, but if we're testing the functional core behind it, we can be very confident that the command is going to be successful.

It's not the end of the world if we can't write tests for something. If the design can be changed so that better tests can be written, that's always preferred. But please, don't bring in proxyquire.

[TrCaM]

Sounds good to me that we can omit testing logging behavior here. I also believe the underlying tested api logic :). In fact the its logic is quite simple too.