This affected (for example?) if the `dtype=object` was used
without a converter, meaning that the default one is used.
And this is currently the last one, which is `string_` (and thus
bytes).

Closes gh-16189

Cleanup from the dropping of python 2

Inheriting from object was necessary for Python 2 compatibility to use
new-style classes. In Python 3, this is unnecessary as there are no
old-style classes.

Dropping the object is more idiomatic Python.

As numpy is Python 3 only, these import statements are now unnecessary
and don't alter runtime behavior.

* BUG: Fix leaking of object descriptor on dtype discovery of `None`

* BUG: Fix reference count leak in string discovery code path

* BUG: Fix two more datetime related reference count bugs

One is leaking only the python integer 1, the other a descriptor.

* BUG: Fix bugs in vectorized string functions error paths

Fixes reference count issues (a leak) in
TestVecString::test_non_existent_method and
TestVecString::test_non_string_array

* BUG: Fix Reference count leak in in128 C-level tests

* BUG: Fix refcount leak in advanced indexing error path

* BUG,MAINT: Refactor indexing dtypes handling in mapiter constructor

Using borrowed references for the dtypes seems much easier to get
the reference counts right.

* BUG: Reference leaks in deprecated datetime with timezone coercion

* BUG: Refcount issue in nonzero 0-d path

* BUG: Fix ufunc.at dtype refcount handling in resolver

* BUG: Fix reference count in nditer python op_axes setup

* BUG: Reference leak in writebackifcopy non-array error path

* BUG: Add missing DECREF in ufunc with dtype type resolution

* BUG: Reference count bugs in io functions

* BUG: Reference count loss in as_c_array C-side tests

* BUG: Leaking of method in object method based ufunc loops

The function could possibly be optimized nicely by checking
that the method will be the same because the types are identical.
OTOH, that may not be correct in dynamically adapted types.

* TST: Clean up cyclic ctypes reference to simplify leak debugging

If we do not clean it up in this test, the collection can take
so long that it affects the following tests when running with
reference leak debugging tools (pytest-leaks).

* BUG: Reference count of raw data for 0-sized unpickling

* TST: Mark tests which must leak references

It really may be time to remove this, considering how annoying this
is, may want to think about getting rid of that behaviour.

Could probably write a multiearraytests C-side function instead.

* BUG: Fix refcount leaks in arr.getield and setfield error paths

* BUG: Fix refcount issue in wheremask

This fix is not the prettiest, since it relies on the wheremask
to be formatted to boolean beforehand correctly.

* TST: Reset StringConvert after mutating it in tests

Or maybe just mark the test?

* BUG: Fix missing static for npy_cache_import in umath funcs.inc.src

* BUG: Fix refcount in multiternew error path

* BUG: Fix npy_ObjectGCD and LCM reference counting

* BUG: Decrement already wrapped outputs on failure

This is not super pretty, but not sure how to do it much better
right now.

* FIXUP: iotools StringConverter._mapper

* FIXUP: as_c_array tests

* FIXUP: String/dtype discovery comment

* FIXUP: Nonzero comment

* FIXUP: mapiternew -- check error return of dtype creation

In principle, at least at this time, this is not possible

* Review F401,F841,F842 flake8 errors (unused variables, imports)

* Review comments

* More tests in test_installed_npymath_ini

* Review comments

Fixes #11028

That function is nose specific and has not worked since `__init__` files
were added to the tests directories.

Minor cleanups of old code to reflect more modern usage.