Remove cylc command wrapper

[kinow]

This is a small change with no associated Issue.

I think now handling which version of Cylc, and from which location to use, will be handled with tools like virtualenv and conda. So I think this file can now be removed @hjoliver ?

Requirements check-list

• I have read CONTRIBUTING.md and added my name as a Code Contributor.
• Contains logically grouped changes (else tidy your branch by rebase).
• Does not contain off-topic changes (use other PRs for other changes).
• Does not need tests (why? code removal).
• No change log entry required (why? e.g. invisible to users).
• No documentation update required.

[hjoliver]

Hmm, maybe not (at least I'm not sure yet).

Suites submit jobs that need to invoke the same cylc version CLI (for status messaging commands, etc.) and some users need to run multiple suites at once at different cylc versions.

At Cylc 7 the cylc wrapper (which is simple and cross-version and changes very infrequently) selects among versions according to $CYLC_VERSION set by suites in their job environments. (Or users could set the version in login scripts if they only need one version).

At Cylc 8 this problem has gotten worse: task jobs need to be able to activate the right virtual environment for the right cylc version before invoking the CLI, and there is no longer any standard install location.

The wrapper might still be the best (only?) way to manage this problem? It could be site (or user) customized to know how to activate the right venv for each installed version of cylc.

I touched on this previously in this comment: cylc/cylc-admin#27 (comment) ...

... which also says: "can the deployment process handle this somehow?" but I don't recall what I was thinking there. Somehow deploy cylc versions in such a way that venv activation is handled automatically for users? (assuming only a single copy of each cylc version is deployed, in some standard location, I guess)?