feat(firebase_ui_auth): Add providerBuilder for sign in and register screen layout customization

[fabiocarneiro]

This PR introduces a major flexibility enhancement for SignInScreen, RegisterScreen, and LoginView.

It adds a providersBuilder callback that gives developers full control over the layout, ordering, and grouping of provider buttons.

Before

Previously, you could only provide a list of providers, and they would be rendered in a fixed order (Email -> Phone -> Email Link -> OAuth) regardless of the order they were passed in the providers list.

SignInScreen(
  providers: [
    EmailAuthProvider(),
    GoogleProvider(clientId: '...'),
    AppleProvider(),
  ],
)

After

With the new optional providersBuilder, you can fully customize the layout, grouping, and ordering of the provider buttons.

SignInScreen(
  providers: [
    EmailAuthProvider(),
    GoogleProvider(clientId: '...'),
    AppleProvider(),
  ],
  // New: Custom layout builder
  providersBuilder: (context, providers, content) {
    return Column(
      children: [
        // Render the Email provider first
        providers.firstWhere((p) => p is EmailAuthProvider),

        const Padding(
          padding: EdgeInsets.symmetric(vertical: 16),
          child: Divider(child: Text("Or sign in with")),
        ),

        // Grouping OAuth providers horizontally
        Row(
          mainAxisAlignment: MainAxisAlignment.spaceEvenly,
          children: [
            providers.firstWhere((p) => p is GoogleProvider),
            providers.firstWhere((p) => p is AppleProvider),
          ],
        ),
      ],
    );
  },
)

💉 Dependency Injection Support

• Added FirebaseAuthProvider to facilitate better dependency injection of the FirebaseAuth instance throughout the widget tree, simplifying how auth state is accessed in child components.

📦 Changes

• Added providersBuilder property to SignInScreen, RegisterScreen, and LoginView.
• Refactored LoginView to use a default builder that preserves legacy behavior (fixed order) if no custom builder is provided.
• Updated OAuth provider buttons to ensure they remain compatible with the new flexible layout system.
• Added missing dependencies to OAuth packages to support the new architecture

Related Issues

None

Checklist

Before you create this PR confirm that it meets all requirements listed below by checking the relevant checkboxes ([x]).
This will ensure a smooth and quick review process. Updating the pubspec.yaml and changelogs is not required.

• I read the [Contributor Guide] and followed the process outlined there for submitting PRs.
• My PR includes unit or integration tests for all changed/updated/fixed behaviors (See [Contributor Guide]).
• All existing and new tests are passing.
• I updated/added relevant documentation (doc comments with ///).
• The analyzer (melos run analyze) does not report any problems on my PR.
• All unit tests pass (melos run test:unit:all doesn't fail).
• I read and followed the [Flutter Style Guide].
• I signed the [CLA].
• I am willing to follow-up on review comments in a timely manner.

Breaking Change

Does your PR require plugin users to manually update their apps to accommodate your change?

• Yes, this is a breaking change.
• No, this is not a breaking change.