Tracking issue for V2

In issues #389 and #158, the need to create a V2 of the go-sdk was identified. This topic was also discussed in the biweekly community meeting on Thursday July 3, 2025.

There are several changes that I would like to see as part of a V2 (not exhaustive):

- [ ] We should also consider #350. In v2, I would like to change the signature of `openfeature.NewClient` to take no parameters, and create a new function called `openfeature.NewDomainClient` that takes a string parameter called `domain`. I want to avoid the names `openfeature.GetClient` and `openfeature.GetDomainClient` as such `Get` functions are not as common in Go and `New` is more idiomatic.

Out of the list above, only number 8 and potentially number 1 (depending on how/where we introduce generics) will cause a breaking change to providers. For number 8, taking a context parameter and returning an error is small enough of a change that I think that is reasonable, especially considering that the StateHandler interface is opt-in and not required to implement.

To implement the above, I think we can actually make a lot of progress before we even create a v2 module. For example, for those identifiers that are to be renamed, we can create the target type/function and deprecate the old one. Then once v2 is created, all we need to do is delete the deprecated identifiers, making that transition a bit easier on our end.

Lastly, before we officially release V2 and deprecate V1, we will want to gather as much feedback as possible about the SDK to ensure that no further breaking changes are anticipated after V2 is released. Once it is released, we will also want to be careful going forward about adding new exported identifiers to ensure that they align with language best practices.