Add new cloudapi/v6 package with auth feature

[AgnesToulet]

What?

This PR introduces a new cloudapi/v6 package (internal for now) that calls the k6 Cloud API v6 instead of v1. It only supports validating token as it's the first step we need to retrieve the stack ID (see #5420). Then, I'll iterate on it to introduce more features.

The main differences with the existing cloudapi package are:

• Use the generated go client (https://github.com/grafana/k6-cloud-openapi-client-go)
• Handle the new v6 response type (the CheckResponse has minor updates and the ResponseError type now contains and parses the k6cloud.ErrorApiModel type)
• I started to clean up the config by removing all references and usage of the LegacyCloudConfigKey (loadimpact). I believe there are many more improvements to be made in this file but it will be easier to review if I keep them in a separate PR - especially as the changes will be visible in the same file instead of having to compare the old and new files side by side).

Why?

We want to migrate to the k6 Cloud API v6 for k6 cloud commands. This is a preliminary work that should help adding support to configure the default stack used by Cloud commands. Then, we'll iterate on it to add more features and use them in the Cloud commands.

Checklist

• I have performed a self-review of my code.
• I have commented on my code, particularly in hard-to-understand areas.
• I have added tests for my changes.
• I have run linter and tests locally (make check) and all pass.

Checklist: Documentation (only for k6 maintainers and if relevant)

Please do not merge this PR until the following items are filled out.

• I have added the correct milestone and labels to the PR.
• I have updated the release notes: link
• I have updated or added an issue to the k6-documentation: grafana/k6-docs#NUMBER if applicable
• I have updated or added an issue to the TypeScript definitions: grafana/k6-DefinitelyTyped#NUMBER if applicable

Related PR(s)/Issue(s)

Part of #4008 and #5009

[inancgumus]

LGTM. Do you think it makes sense to add some context to returned error messages to see what went wrong when something fails, such as, "validating token: %w", err?