Ensure cudf internals use pylibcudf in pure Python mode

[vyasr]

Description

In the short term, cudf internals will be the primary client of pylibcudf, and in the intermediate term cudf internals will likely remain the most exhaustive test of pylibcudf's API. While pylibcudf is designed to be used as either a Python or a Cython library, Python usage is expected to be the much more common entry point. Therefore, it would be best for cudf to use pylibcudf solely as a Python library. This is also useful because it would theoretically allow us to turn cudf into a pure Python library, or at least something much closer to it. In the long run we will likely want to leverage pylibcudf's Cython to accelerate parts of cudf, but that isn't something we should aim for the in the first pass. Switching to pure Python mode is also important because of certain limitations with Cython scoped enum support that will hopefully be fixed soon in Cython itself.

Checklist

• I am familiar with the Contributing Guidelines.
• New or existing tests cover these changes.
• The documentation is up to date with these changes.

[shwina]

I support this proposal -- ultimately, I think we likely don't want two layers of Cython between libcudf and cuDF anyway.

[vyasr]

/merge