Loss of flexibility when using generated flag accessors

When using generated flag accessors, at least in Go, the user no longer has access to the client. This has several implications:

1. There is no way for the user to evaluate a flag using a client bound to a provider other than the default provider. Of course this can still be done by creating a new client and performing the evaluations without using the generated code, but that defeats the purpose of generating the code.
2. A user cannot perform the usual actions on the client, such as setting an evaluation context or calling client.Track.

https://github.com/open-feature/cli/blob/main/internal/generators/golang/golang.tmpl

Suggestions:

1. Export the names of the generated flags as constants so that users can access the flag names if they need to.
2. Maybe adjust the schema by adding an optional domain field to each flag that specifies which domain to use to evaluate that flag.
3. An alternative to point 2: maybe even go as far as to have users (in the flag manifest file) specify an optional array of domains for which they want to generate flags/clients. Then generate flag accessors and a client for every domain that was listed in the flag manifest file.
4. Export the generated client(s) so that users can access them if needed in order to, for example, add hooks at the client level.

Start with internal/generators/golang/golang.tmpl and review how generated flag accessors currently obtain and use the client. Clarify which proposal should be implemented—exported flag names, configurable domains, generated clients, or another API—and define how users will retain provider, evaluation-context, and client-level actions. Done means the selected design is implemented in generated Go output and its behavior is verified.