Consider moving artifacts into sub-packages

[toddbaert]

Potentially consider rearranging packages. For example, the SDK has a noop provider, an in-memory provider, a testing provider, and soon a multi-provider. Should all of these live under openfeature/providers in their own packages? Or are we OK with keeping that structure as is?

Consider moving some functions/artifacts into sub-packages.

[jblacker]

I think a lot of components can be moved to subpackages. We can then create exported aliases for them back in the openfeature package to prevent breaking changes until v2 comes out.

Some things that I think would make sense moved to their own package from the existing openfeature package:

• hooks.go & hooks_test.go to the existing hooks package
• move any provider related code into an exported provider package including the FeatureProvider interface
• NoopProvider into it's own new package or within the provider package (I can see this one either way)
• create internal/evaluation to include things like providerReference, evaluationImpl
• create internal/eventing to include things like clientEvent, eventingImpl, eventExecutor

The remaining items most likely belong in the openfeature root package with exception of mocks & interfaces as I know we want to break those up further.

Personally, I don't think we should unexport the mocks, but I do believe that they should be relocated. Once we break up the interfaces more I think we should regenerate them into the testing package to allow them to be optional. The reason for this is that they can be quite useful when writing tests for custom providers & hooks. I know there are other mocking frameworks out there and not everyone uses ubermock though. Maybe another option would be to put them into their own package nested under testing like testing/mocks. This would allow for usage internally as well as still allowing provider & hook developers to leverage them.