Feat: Quality of life improvements

[ammarahm-ed]

This PR adds some quality of life improvements to NativeScript CLI.

• A new command, ns start that can run and manage Android & iOS apps side by side. The goal is to avoid restarting the CLI for most basic things like cleaning project/restarting the app.

• The CLI is interactive when you run ns start or ns run * commands. Initially I have enabled the following key commands:

  a — Run android app
  i — Run iOS app
  A — Open android project in Android Studio
  I — Open iOS project in Xcode
  r — Rebuild native app if needed and restart
  R — Force rebuild native app and restart
  w — Toggle file watcher (Disables/Enables webpack/native changes watch etc)
  c — Clean project
  n — Install dependencies

  Do let me know if there are any other key commands you would like to see.

One thing still missing is ability to connect to an exisiting app on a device without rebuilding, just connecting HMR and reloading the app that I really want to add.

Also for the ns start command, there could be a way to toggle logging and show minimum logs other than those from the app with the option to enable complete logs.

• The CLI also has a new header similar to preview CLI that prints whenever you run any command.

Here's the new look:

PR Checklist

• [x] The PR title follows our guidelines: https://github.com/NativeScript/NativeScript/blob/master/tools/notes/CONTRIBUTING.md#commit-messages.
• [ ] There is an issue for the bug/feature this PR is for. To avoid wasting your time, it's best to open a suggestion issue first and wait for approval before working on it.
• [x] You have signed the CLA.
• [ ] All existing tests are passing: https://github.com/NativeScript/nativescript-cli/blob/master/CONTRIBUTING.md#contribute-to-the-code-base
• [ ] Tests for the changes are included.

[NathanWalker]

Couple initial comments:

• ns start as interactive menu is excellent - and consistent with other workflows that have been enabled throughout {N} open source in general - super helpful
• The prompt order and grouping I may suggest the following (attempts to better group things to clarify):

Debug with Chrome DevTools Enabled:
a — Debug Android app 
i — Debug iOS app

Dev Workflow:
 r — Rebuild native app if needed and restart
 R — Force rebuild native app and restart
 w — Toggle file watcher (Disables/Enables webpack/native changes watch etc)

Open Platform Projects:
 A — Open Android project in Android Studio
 I — Open iOS project in Xcode

Project Management:
 c — Clean project
 n — Install dependencies

• Changing 'run' to 'debug' since run/debug have different meanings and uses in CLI. This start menu can use debug as default since most useful. One could still ns run on their own - it's more advanced and would argue less used command but allows multiples connected devices to be run at same time. Whereas debug always enabled chrome debugger and uses a targeted device.
• The debug usage I think might be useful to auto open chrome devtools rather than simply printing the url. This is debateable but given most are developing with the need to have devtools active/enabled from start, opening url on debug runs may be useful.

[ammarahm-ed]

The prompt order and grouping

We can improve the order but I am not sure if it's a good idea to group them. I understand that we want to make things more clear but it will make the initial header + key command help quick long and take more space. Maybe just keeping the relevant commands together is good enough.

Changing 'run' to 'debug' since run/debug have different meanings and uses in CLI. This start menu can use debug as default since most useful. One could still ns run on their own - it's more advanced and would argue less used command but allows multiples connected devices to be run at same time. Whereas debug always enabled chrome debugger and uses a targeted device.

I personally have been using run command most of the time. I think you aren't always in the debug mode and needing a chrome tab opened to debug the app. Most of the time console.log does it's job until you hit something that needs debugging in chrome. A key command like press "d" to start debugging can work too for that case.