pd.Index ignores dtype for integer inputs (explicit or inferred), always returning int64
#### Code example / reproduction

```python
### pd.Index will always coerce integer inputs to int64, regardless of original dtype
#   or explicit dtype arg
# Default behavior assumes int64, as expected
pd.Index(np.arange(10)).dtype  # dtype('int64')
# Input values are ignored, i.e. no inferring of dtype results
np.arange(10, dtype=np.int8).dtype  # dtype('int8')
pd.Index(np.arange(10, dtype=np.int8)).dtype  # dtype('int64')
# Explicit dtype argument doesn't affect behavior
pd.Index(np.arange(10, dtype=np.int8), dtype=np.int8).dtype  # dtype('int64')

# Naturally, DataFrame yields the same, whether or not an index is provided
# Default behavior assumes int64, as expected
pd.DataFrame(np.arange(10)).index.dtype  # dtype('int64')
# Implicit dtype of values provided to be used as index
np.arange(10, dtype=np.int8).dtype  # dtype('int8')
pd.DataFrame(np.arange(10), index=np.arange(10, dtype=np.int8)).index.dtype  # dtype('int64')
# As shown above, one cannot create an Index beforehand to pass to DataFrame(), because
# the Index instance itself is/was already coerced to Int64Index
```
#### Problem source
The problem traces down to `Index.__new__` in [indexes.base.py around line 240](https://github.com/pandas-dev/pandas/blob/master/pandas/indexes/base.py#L243-L245) wherein an `Int64Index` is always returned, regardless of the original values' `dtype`:
```python
## pandas-dev
            if is_signed_integer_dtype(data.dtype):
                from .numeric import Int64Index
                return Int64Index(data, copy=copy, dtype=dtype, name=name)
## v19.2, lines 238-240:
            if issubclass(data.dtype.type, np.integer):
                from .numeric import Int64Index
                return Int64Index(data, copy=copy, dtype=dtype, name=name)
```

Various previous steps take care to follow inferred `dtype` and/or that explicitly specified via `dtype` parameter, but this information is effectively discarded. If this is the preferred behavior, there might be a warning emitted or some other method of notifying that type coercion had taken place.

#### Suggested behavior / discussion

I would argue, though, that the preferred behavior would be to utilize the typing requested. This would more closely follow the expressed intent of `RangeIndex` in implementing a "memory-saving special case" but using the minimum memory required to represent the index values.

#### Example use case
To provide a legitimate use case, I'm currently working on a project involving simple calculations (resulting in various integer values, but all of which fall within the -127,128 int-8 range) on massive numbers of elements, for example:

```python
"{:.2f} MB".format(np.array([1,]*len(rulesdf)).nbytes / 1024**2)
# ^  '3814.70 MB', default int64
"{:.2f} MB".format(np.array([1,]*len(rulesdf), dtype=np.int8).nbytes / 1024**2)
# ^  '476.84 MB' using int8
## Above example uses ~500 million elements, but project needs are ~tens-of-billions
```

I've had to add steps to convert data from pandas DataFrame to numpy arrays in order to conserve memory by forcing all values to `np.int8` (or similarly `np.int16` in some cases), and only later returning to DataFrame and/or Series values once various transformations are done to reduce the numbers of elements involved (unfortunately, a lot of those transformations would be more easily done as a pandas DataFrame, to boot!).


From what I can find, it looks like that may require a different `NumericIndex` subclass, which could perhaps provide a base class for alternative `RangeIndex` and/or `Int__Index` classes. But I'm not particularly well versed on what else might exist, this is only what I've found so far. 

#### Environment / Version Info

These examples were all done locally on a MacBook Pro, macOS 10.12.3. But the issue was originally come across on various AWS EC2 servers, all running Ubuntu. I've provided the `show_versions()` info for one EC2 instance, but found the same on c4.4xlarge & c4.8xlarge instances.

<details>
## Local MacBook

INSTALLED VERSIONS
------------------
commit: None
python: 3.5.2.final.0
python-bits: 64
OS: Darwin
OS-release: 16.4.0
machine: x86_64
processor: i386
byteorder: little
LC_ALL: None
LANG: en_US.UTF-8
LOCALE: en_US.UTF-8

pandas: 0.19.2
nose: None
pip: 9.0.1
setuptools: 28.8.0.post20161110
Cython: None
numpy: 1.11.3
scipy: 0.18.1
statsmodels: None
xarray: None
IPython: 5.1.0
sphinx: None
patsy: None
dateutil: 2.6.0
pytz: 2016.10
blosc: None
bottleneck: None
tables: None
numexpr: None
matplotlib: 1.5.3
openpyxl: None
xlrd: None
xlwt: None
xlsxwriter: None
lxml: None
bs4: None
html5lib: None
httplib2: None
apiclient: None
sqlalchemy: 1.1.4
pymysql: None
psycopg2: 2.6.2 (dt dec pq3 ext lo64)
jinja2: None
boto: None
pandas_datareader: None

## AWS EC2 Micro instance
INSTALLED VERSIONS
------------------
commit: None
python: 3.5.2.final.0
python-bits: 64
OS: Linux
OS-release: 4.4.0-64-generic
machine: x86_64
processor: x86_64
byteorder: little
LC_ALL: None
LANG: en_US.UTF-8
LOCALE: en_US.UTF-8

pandas: 0.19.1
nose: None
pip: 9.0.1
setuptools: 28.8.0.post20161110
Cython: None
numpy: 1.11.2
scipy: 0.18.1
statsmodels: None
xarray: None
IPython: 5.1.0
sphinx: None
patsy: None
dateutil: 2.6.0
pytz: 2016.7
blosc: None
bottleneck: None
tables: None
numexpr: None
matplotlib: 1.5.3
openpyxl: None
xlrd: None
xlwt: None
xlsxwriter: None
lxml: None
bs4: None
html5lib: None
httplib2: None
apiclient: None
sqlalchemy: 1.1.4
pymysql: None
psycopg2: 2.6.2 (dt dec pq3 ext lo64)
jinja2: 2.8
boto: None
pandas_datareader: None
</details>
