Remove evaluation functions returning errors

[toddbaert]

[Suggested by @toddbaert] We could consider removing these functions entirely. They return errors directly, which add complexity and is arguably against the spec, which says evaluation methods should never abnormally terminate (returning a non-nil error in Go signals an abnormal termination equivalent to throwing IMO). People actually complained about the ergonomics of these and we implemented the non-error-returning versions in response. The "detailed" evaluation methods also return errors, and we have no "non-error" variant. We should consider our options here to make these consistent and idiomatic.

Consider removing evaluation functions returning errors. This is somewhat against spec, and people complained about the ergonomics long ago, causing us to build the non-error-returning versions.

[thomaspoignant]

Just to be sure, the only way we will have to know that an error occurred will be by using the evaluation details?

I am not against that, but this is a big breaking change for large code base using OpenFeature since all the evaluation methods will be somehow to be rewritten.
If we do something like that we should expect some of our users to stay with the SDK v1 for quite a long time if they have a large adoption of OpenFeature.