* Simplify logic for encoding kwarg in _decode_line.

* Remove unnecessary else branch from split_line.

* MAINT: rm else branch from loadtxt.

* MAINT: re-nest encoding parsing.

Co-Authored-By: mattip <matti.picus@gmail.com>

* condense return statement.

Co-authored-by: mattip <matti.picus@gmail.com>

Some more Python 2 cleanup.

Co-authored-by: Eric Wieser <wieser.eric@gmail.com>

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

The previous logic here was very hard to follow, as loop variables were being used after the loop ended, and being conditionally overwritten.

Also fix the docstring indentation

These dtypes do not really make sense as instances. We can (somewhat)
reasonably define np.dtype(np.int64) as the default (machine endianess)
int64. (Arguably, it is unclear that `np.array(arr_of_>f8, dtype="f")`
should return arr_of_<f8, but that would be very noisy!)

However, `np.integer` as equivalent to long, is not well defined.
Similarly, `dtype=Decimal` may be neat to spell `dtype=object` when you
intend to put Decimal objects into the array. But it is misleading,
since there is no special meaning to it at this time.

The biggest issue with it, is that `arr.astype(np.floating)` looks
like it will let float32 or float128 pass, but it will force a
float64 output! Arguably downcasting is a bug in this case.

A related issue is `np.dtype("S")` and especially "S0". The dtype "S"
does make sense for most or all places where `dtype=...` can be
passed. However, it is conceptionally different from other dtypes, since
it will not end up being attached to the array (unlike "S2" which
would be). The dtype "S" really means the type number/DType class
of String, and not a specific dtype instance.