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

既存の `ng new` と `ng generate` の動作、およびリンクされている Angular workspace のファイル構成ドキュメントを確認することから始めます。現在の `--create-application=false` フローを、要求されているアプリケーション、ライブラリ、マルチアプリのユースケースと比較します。実装前に、workspace の用語とコマンドの境界について合意された方向性が定まっていることが完了の条件です。

索引モデルが issue の本文から書いたものです。