CH-151 Application generation improvements

[condar-metacell]

Closes CH-151

Significant refactoring of both harness-application and harness-generate plus added the features listed in the ticket as well as:

1. Adding support for an --app-name/-a option to all harness-generate calls which restricts clients and servers to only generate for the specified app
2. Generating a .ch-manifest file in harness-application to help simplify the logic in harness-generate
3. Improving the interface for harness-generate by using sub-parser commands
4. Add the ability to generate only typescript or python client libraries with a flag when using harness-generate

Breaking Changes This is a breaking change to the command line interface of harness-generate, the following are the changes that will need to be accounted for:

1. The harness-generate command now has 4 sub-commands: all, clients, models and servers which will run the generation script for all resource types, client code, models and server stubs respectfully.
2. The old default of harness-generate which generated all types of resources is no longer valid, instead use harness-generate all
3. The flag -c/--clients has been removed, instead use harness-generate clients
4. The flag -m/--models has been removed, instead use harness-generate models
5. The -s/--server command line option has been removed and it's responsibilities split:
   1. To generate only server stubs use harness-generate servers
   2. To restrict which app gets servers generated use -a/--app-name
6. All generation modes support a -a/--app-name option; client and server generation is restricted to the app selected.

...

Use both harness-application and harness-generate to create apps, stubs and clients. harness-deployment and skaffold should work from a newly created app without any additional steps needed.

...

Sanity checks:

• [x] The pull request is explicitly linked to the relevant issue(s)
• [x] The issue is well described: clearly states the problem and the general proposed solution(s)
• [x] In this PR it is explicitly stated how to test the current change
• [x] The labels in the issue set the scope and the type of issue (bug, feature, etc.)
• [x] The relevant components are indicated in the issue (if any)
• [x] All the automated test checks are passing
• [x] All the linked issues are included in one Sprint
• [x] All the linked issues are in the Review state
• [x] All the linked issues are assigned

Breaking changes (select one):

• [ ] The present changes do not change the preexisting api in any way
• [x] This PR and the issue are tagged as a breaking-change and the migration procedure is well described above

Possible deployment updates issues (select one):

• [x] There is no reason why deployments based on CloudHarness may break after the current update
• [ ] This PR and the issue are tagged as alert:deployment

Test coverage (select one):

• [x] Tests for the relevant cases are included in this pr
• [ ] The changes included in this pr are out of the current test coverage scope

Documentation (select one):

• [x] The documentation has been updated to match the current changes
• [ ] The changes included in this PR are out of the current documentation scope

Nice to have (if relevant):

• [ ] Screenshots of the changes
• [ ] Explanatory video/animated gif