PERF: improve iloc list indexing
Did a profile of `iloc` using a list indexer, and noticed a few parts that seemingly can be optimized rather easily:

- convert early to array, and keep as array
- do not validate the input for out of bounds (this validation is also (and much faster) done in `np.take`)
- do not validate kwargs (for numpy compat) (-> could define a `_take` method that does not do this for internal usage?)
- use fastpath for resulting Series creation

The failing tests are currently just the ones that checked for the kwarg validation (and one failing test due to the fastpath taken where object datetimes are not coerced to datetime64).

Compared to master, I get up to 40 to 60% improvement on some simple tests:

PR:
```
In [1]: s = pd.Series(np.random.randn(10000))

In [2]: s.iloc[10]
Out[2]: 0.91268983379322421

In [3]: %timeit s.iloc[[10]]
The slowest run took 14.18 times longer than the fastest. This could mean that an intermediate result is being cached.
10000 loops, best of 3: 47.3 µs per loop

In [4]: indexer = list(range(10, 30)) + list(range(50,80))

In [5]: %timeit s.iloc[indexer]
The slowest run took 5.92 times longer than the fastest. This could mean that an intermediate result is being cached.
10000 loops, best of 3: 49.8 µs per loop

In [6]: indexer = list(range(10, 30)) + list(range(50,800))

In [7]: %timeit s.iloc[indexer]
10000 loops, best of 3: 104 µs per loop
```

master:
```
In [1]: s = pd.Series(np.random.randn(10000))

In [2]: s.iloc[10]
Out[2]: -1.4152272792497846

In [3]: %timeit s.iloc[[10]]
The slowest run took 6.70 times longer than the fastest. This could mean that an intermediate result is being cached.
10000 loops, best of 3: 103 µs per loop

In [4]: indexer = list(range(10, 30)) + list(range(50,80))

In [5]: %timeit s.iloc[indexer]
The slowest run took 4.12 times longer than the fastest. This could mean that an intermediate result is being cached.
10000 loops, best of 3: 131 µs per loop

In [6]: indexer = list(range(10, 30)) + list(range(50,800))

In [7]: %timeit s.iloc[indexer]
The slowest run took 17.01 times longer than the fastest. This could mean that an intermediate result is being cached.
1000 loops, best of 3: 247 µs per loop
```

There are some details to work out, but already putting it up here for discussion (and need to run the benchmark suite).

From the remaining time that iloc takes, a large part is spent in the creation of the actual result (the new series): creating a new index (~ 17%), creating a new series based on the values and index (~ 32%). So in total almost half of the time, and thus wondering if this is not possible to speedup.