Better support `ng new` use cases

# 🚀 Feature request

/cc @mgechev

### Command (mark with an `x`)
- [X] new
- [X] generate

### Description

We should rethink some of the DX around `ng new`, as it was originally intended to make new Angular applications, but has expanded somewhat, particularly with monorepos. There are three things in particular which are a bit awkward:

1. There is no way to create an Angular library (using the CLI) without using a monorepo structure. This may not be desired and makes library authorship a little more awkward.
1. To use a monorepo structure, users are supposed to use `ng new --create-application=false`, which is a pretty awkward syntax and doesn't make clear that this is intended for a monorepo/multi-app workspace.
1. Reevaluate the definition of "workspace". I can't speak for others, but I always interpreted a "workspace" as effectively a monorepository for Angular apps. Looking through [docs](https://angular.io/guide/file-structure), it seems that anything with an `angular.json` file is technically a "workspace", so `ng new` technically creates a workspace, even though it isn't a monorepo. I think this definition of "workspace" only really applies internally so we should think more critically about the language here.

Additional context: https://twitter.com/justinfagnani/status/1373336274384293889

### Describe the solution you'd like

I'm thinking we could add an extra flag to `ng new` to decide whether to make a standalone application (`ng new --type app`), a multi-app workspace (`ng new --type workspace`, equivalent to today's `ng new --create-application=false`), or a standalone library (`ng new --type library`). Note that `ng new --type app` and `ng new --type library` both *technically* create a "workspace" per the above definition. We might want to either tweak the definition of "workspace" to mean "a multi-app Angular repo" or use something like `ng new --type empty-workspace`.

This would be distinguished from `ng generate` because `ng new` makes a new repository while `ng generate` works within an existing repository. Arguably we should merge `ng new` and `ng generate` (maybe inferring from file path context whether a new repository is required).

Some of the broader questions we should discuss:

1. How should we position Angular "workspaces"? Are they for monorepositories or not?
2. How should `ng new` and `ng generate` work together or be merged?

### Describe alternatives you've considered

Apparently you can use `ng-packagr` to generate a library without a workspace, but you're losing a lot of the benefits of the CLI by doing so: https://twitter.com/Splaktar/status/1373373386802479105

Start by reviewing the existing `ng new` and `ng generate` behavior and the linked Angular workspace file-structure documentation. Compare the current `--create-application=false` flow with the requested application, library, and multi-app use cases. Done requires an agreed direction for workspace terminology and command boundaries before implementation.

Written by the indexing model from the issue text.