docs: refactor workspaces, projects, and targets

[stefanicjuraj]

• Renamed Workspaces to Targets
  • refactor: rename Workspace to Target daytona#1297
• Renamed Projects to Workspaces
  • refactor: rename project to workspace daytona#1299

[Tpuljak]

Commenting here since I can't comment on unchanged code.

We need to refactor the container registries page. We no longer have CR commands.
Instead, they are managed through env variables.

(Similar setup to Codespaces - https://docs.github.com/en/codespaces/reference/allowing-your-codespace-to-access-a-private-registry)

Mention that the user can set "global" CRs with daytona env set and per-workspace CRs by adding those envs into a workspace (or workspace template)

[Tpuljak]

Can't put the comment above since it's unchanged, but please update the creation logs. They're different now since there are no more projects

Also, I would remove the TC selection stuff. It just bloats this section. We can just say (for example) If you don't have a default target set (tip: daytona target set-default), you will be prompted to select a target for that workspace

[Tpuljak]

@stefanicjuraj the logs are still wrong. There is no more WORKSPACE tags.

 local   | ✓ Request submitted
 kubectl | Creating workspace kubectl (c3f44c5c14bf)
 kubectl | Pulling image...
 kubectl | Pulling from daytonaio/workspace-project
 kubectl | Digest: sha256:2bbb1ea57364e2bba5d15c02a7d8b0cafd633fd1881ab6ab60ef2ed95aec6edc
 kubectl | Status: Image is up to date for daytonaio/workspace-project:latest
 kubectl | ✓ Image pulled successfully
 kubectl | UIDs and GIDs are the same (1000:1000).
 kubectl | Cloning into '/workdir/kubectl'...
 kubectl | UIDs and GIDs are the same (1000:1000).
 kubectl | ✓ Workspace kubectl created

Note: local is the name of the target and kubectl is the name of the workspace

[Tpuljak]

The list command view was updated. Update the table below

[Tpuljak]

This is how it should look like

[Tpuljak]

To set environment variables for a specific Workspace, set the environment variables within the Workspace directory.

This doesn't make much sense.

Mention that to set "server-wide" CRs (on every new workspace), users use daytona env and to set on a per-workspace basis they can set the envs on templates or on workspaces with --env when creating

[Tpuljak]

Remove the note

[Tpuljak]

In line with the convo we had on Slack, let's assume that the user has Target Configs configured and they just need to choose it to create a target.

We leave creating the TC for the TC page

[Tpuljak]

This is how it should look like