Use post-start hook to send telemetry for team members

What does this merge request do and why?

This MR introduces sending telemetry regarding the workspace setup duration for team members from within the post-start hook.

We can do this for team members, because they are automatically opted-in to the Telemetry sending and there is no interactivity needed in this case.

We can still not do this for the wider community at large and will therefor need to keep the Ruby code powering the VSCode task for now.

However, because community members cannot create workspaces for the monolith, we will not need to create a VSCode task there.

Additionally this MR adds a project_name variable to the telemetry, basically consisting of the underlying repository name for that workspace. This allows us to differentiate between workspaces in the monolith and workspaces in the GDK repo or other projects.

Closes #2836 (closed) Contributes to #2951 (closed)

How to set up and validate locally

Numbered steps to set up and validate the change are strongly suggested.

1. Create a workspace for this branch. Do not forget to set GDK_SELF_UPDATE to 0, so that no scripts are overwritten.
2. Open the workspace and wait for the setup to finish, running tail -f /projects/workspace-logs/poststart-stdout.log in the shell.
3. Observe that there is debug output related to the sent telemetry and it matches the recording timings.
4. Observe that the VSCode task potentially echoed out a message indicating that telemetry won't be sent, or just a success message.
5. Observe that the timings in tail -f /projects/workspace-logs/poststart-stdout.log match the ones from /projects/workspace-logs/poststart-stderr.log, where a part of the setup, including the gdk send-telemetry command will be logged, even if it succeeds.
6. Observe that the ${GDK_ROOT}/.cache/.gdk_setup_telemetry_sent exists.
7. Observe that the gdk send-telemetry command contains a project_name extra argument.

Impacted categories

The following categories relate to this merge request:

• gdk-reliability - e.g. When a GDK action fails to complete.
• gdk-usability - e.g. Improvements or suggestions around how the GDK functions.
• gdk-performance - e.g. When a GDK action is slow or times out.

Merge request checklist

• This MR references an issue describing the change.
• This change is backward compatible. If not, please include steps to communicate to our users.
• Tests added for new functionality. If not, please raise an issue to follow-up.
• Documentation added/updated, if needed.
• Announcement added, if change is notable.
• gdk doctor test added, if needed.

Closes #2951 (closed)