Avoid cudf.dtype internally in favor of pre-defined, supported types

[mroeschke]

Description

xref #12494 and #12495

cudf.dtype is useful when cudf is passed a dtype argument from a user to perform inference on the input to make it cudf-compatable. Internally, we don't need this inference because we know the exact types to be passed & that are supported by cudf (columns), so this PR avoids calling cudf.dtype internally.

Generally:

• Define CUDF_STRING_DTYPE as a definitive cudf Python string type instead of cudf/np.dtype("O"/"object", "str")
• Prefer using np.<type> instead of "<type>" (using np. like an enum namespace)

Checklist

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

[vyasr]

For the record I did some quick timings to see if these are worth caching (they're probably not):

In [2]: %timeit np.dtype(np.int64)
129 ns ± 0.738 ns per loop (mean ± std. dev. of 7 runs, 10,000,000 loops each)

In [6]: %timeit np.iinfo(np.dtype(np.int64))
563 ns ± 1.12 ns per loop (mean ± std. dev. of 7 runs, 1,000,000 loops each)

In [7]: %timeit np.iinfo(np.dtype(np.int64)).max
633 ns ± 5.25 ns per loop (mean ± std. dev. of 7 runs, 1,000,000 loops each)

[vyasr]

/merge