feat: add short-form lit:/// URLs, deprecate studio cp/ls/rm

[owbone]

Allow lit:// URLs of the form lit:///<resource_type>/<path>, which infer the org and teamspace from the context.

lightning studio cp/ls/rm currently support an undocumented short-form URL of the form lit://<teamspace>/studios/<studio>/<path> or lit://<studio>/<path>. Rather than continuing to support those elsewhere, just mark those commands as deprecated in favour of plain cp/ls/rm with the new short-form URLs.

[dhedey]

My initial take - I\m not too sure on the clarity of lit:/// but would be OK supporting it.

Some alternatives:

• lit-drive://
• lit://drive/
• lit://team/
• lit://this-team/
• lit://this-teamspace/
• lit://teamspace/

Maybe on balance lit:/// is actually the best if we explain it clearly! :)

Also, is this a good time to replace <owner> with <organization> in all the docs? It was quite confusing what "owner" was when I read the docs today to show a client the CLI cp command.

[owbone]

My initial take - I\m not too sure on the clarity of lit:/// but would be OK supporting it.

Some alternatives:

* `lit-drive://`

* `lit://drive/`

* `lit://team/`

* `lit://this-team/`

* `lit://this-teamspace/`

* `lit://teamspace/`

Maybe on balance lit:/// is actually the best if we explain it clearly! :)

Also, is this a good time to replace <owner> with <organization> in all the docs? It was quite confusing what "owner" was when I read the docs today to show a client the CLI cp command.

This is an established URL pattern to skip the authority, e.g. file:///, so it's well supported and easy to parse. They aren't necessarily drive specific and, unless we introduce a more magical syntax (e.g. lit://~/studios/...) (which would probably also be fine), then the other options are slightly ambiguous.

[dhedey]

This is an established URL pattern to skip the authority, e.g. file:///, so it's well supported and easy to parse

Nice, good point 👍