Re-evaluate OpenFeature file naming

[maxveldink]

While working on #72, I encountered a rule violation around spec naming. I believe this was because the files were named openfeature while the constant we're defining is OpenFeature. In addition to violating the rule, this naming convention is surprising, and I'd expect the files to be named open_feature. This would also be an issue if we switched to the Zeitwerk autoloader.

I'm curious about the naming choice and if we'd be open to renaming, especially while we do not have a major version.

[mschoenlaub]

I am highly in favor of keeping the module named OpenFeature and naming the file open_feature.
After all, it's two words and this way it would be aligned with the python-sdk.
IMHO this is just what users of the module would expect.

I came across a similar issue where in the inital RBS file the module was named Openfeature. My guess is that both issues stem from the scaffolding that had been done in the beginning.

[toddbaert]

Our naming conventions say both open feature and openfeature are acceptable (one vs two words). The casing should really match whatever the language/packaging idioms recommend.

As we aren't yet at a 1.0, this is a good time to make breaking changes (if needed). I won't weigh in on what specifically is more "rubyesque".

[maxveldink]

Created #90 to address the file change!

One last thing would be renaming the entire package. Currently, it's openfeature-sdk, which isn't too wild. The only thing we might consider is renaming to open_feature-sdk and pointing those older packages to the new one.