Allow configuring project-level provider settings within onboarding flow

What does this MR do and why?

Update product analytics onboarding flow, Self-managed provider card.

When onboarding product analytics with a Self-managed provider, there is now no manual redirect to the project settings page required for adding out any missing project-level settings. Instead a new modal directly within the onboarding flow allows configuring the settings.

Configurator form field label is slightly different to the main settings page (no "snowplow" in the name) to closer match our docs.

Editing settings work stream:

• Fetch project-level provider settings via GraphQL !160657 (merged)
• Extract clear settings modal to standalone component !160659 (merged)
• Remove redirect when clearing self-managed project-level provider settings !160669 (merged)
• Allow configuring project-level provider settings within onboarding flow <-- you are here

MR acceptance checklist

Please evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

Screenshots or screen recordings

Before	After
	(form validation)
	(loading state)
	(request failed)

How to set up and validate locally

1. Follow these instructions to setup Product Analytics in GDK.
2. Create a new project / visit a not-onboarded project.
3. Ensure you are signed in as a maintainer or higher role.
4. If you are reusing an existing project, ensure there are no project-level provider settings configured at Project > Settings > Analytics > Data Sources > Product Analytics
5. Visit Project > Analytics > Analytics dashboards.
6. Click "Set up"
7. On the self-managed provider card, un-check Use instance-level settings, and then click Use self-managed provider
8. Verify the new modal opens and allows you to configure provider settings as expected.
9. Onboarding flow continues once submitted.

Note: to test the start of the onboarding flow multiple times on the same project, this patch can be applied to prevent the actual graphql mutation being sent (you will land on the loading state and sit there forever):

patch

diff --git a/ee/app/assets/javascripts/product_analytics/onboarding/components/providers/provider_selection_view.vue b/ee/app/assets/javascripts/product_analytics/onboarding/components/providers/provider_selection_view.vue
index 074922f78dac..6cc5811240b4 100644
--- a/ee/app/assets/javascripts/product_analytics/onboarding/components/providers/provider_selection_view.vue
+++ b/ee/app/assets/javascripts/product_analytics/onboarding/components/providers/provider_selection_view.vue
@@ -62,7 +62,8 @@ export default {
     onConfirm(instanceInitializingSvgPath) {
       this.instanceInitializingSvgPath = instanceInitializingSvgPath;
       this.isInitializingInstance = true;
-      this.initialize();
+      // this.initialize();
+      console.log('initialize skipped, onboarding would have been triggered.');
     },
     onError(err) {
       this.isInitializingInstance = false;

Related to #462964 (closed)