Java and node Allow passing raw options to execute but Go does not. This PR adds the change.

removal of WithExecuteOptions:
The removal of WithExecuteOptions on the Pipeline builder and the shifting of its arguments directly into Execute(ctx, opts...) is a design pattern choice rooted heavily in idiomatic Go practices and separation of concerns.

Here is a detailed breakdown of exactly why this change was made:

1. Separation of Definition vs. Execution
   A Pipeline struct represents an immutable definition of a query. It builds a data structure that describes what data you want (e.g., Where(...), Select(...), Aggregate(...)).
   Execution options, on the other hand, describe how you want the backend to process that query (e.g., "return explain metrics", "use a specific index mode", "pass these raw backend flags").
   If WithExecuteOptions was left on the Pipeline, you would be coupling the query's definition with its execution metadata. By moving ExecuteOption to be a variadic argument on the Execute() method itself, you completely separate the two concerns.

2. Reusability of the Pipeline
   Because the definition is now separated from the execution telemetry, a developer can build a pipeline once and execute it in multiple different ways without having to clone or mutate it:

   // 1. Define the Pipeline once
   myPipeline := client.Pipeline().Collection("books").Where("published", ">", 1990)
   
   // 2. Execute it normally in production
   res := myPipeline.Execute(ctx)
   
   // 3. Execute the exact same pipeline structure in a testing environment to analyze its performance
   explainRes := myPipeline.Execute(ctx, firestore.WithExplainMode(firestore.ExplainModeAnalyze))

   If WithExecuteOptions existed, the developer would have to fork the pipeline state to achieve this (myPipeline.WithExecuteOptions(...)).

3. The Idiomatic "Functional Options" Pattern
   In Go, it is standard practice for functions that trigger a network request or a concrete action (Get, Set, Execute) to accept operational modifiers as trailing variadic arguments.
   If you look at the rest of the Google Cloud SDKs (or even standard library packages like grpc), you will see this pattern everywhere:

   • client.Collection("c").Doc("d").Get(ctx, firestore.opts...)
   • client.RunTransaction(ctx, f, firestore.opts...)
     Moving opts ...ExecuteOption directly into Execute(ctx context.Context, opts ...ExecuteOption) ensures maximum consistency with the rest of the Go SDK's API surface.