WIP: multi-timezone handling for array_to_datetime
cc @mroeschke 

ATM `array_to_datetime` handles strings and datetime objects very differently, with `conversion.datetime_to_datetime64` picking up (some of) the slack.  This unifies the treatment of strings/datetimes within array_to_datetime, rendering `conversion_to_datetime64` (and some ugly try/excepts in `pd.to_datetime`) unnecessary.

As of now there are still 5 tests failing locally; resolving them will involve some design decisions.

1) This PR introduces cases where dateutil's UTC or dateutil tzoffsets are returned while the test expects the equivalent pytz object.  We can either a) try to convert them within `array_to_datetime` to more consistently return pytz objects, b) change the tests to expect the dateutil versions, or c) change the tests to not care.

2) In the status quo we do (and test) something weird:

```
vals = [pd.Timestamp('2011-01-01 10:00'), pd.Timestamp('2011-01-02 10:00', tz='US/Eastern')]
# i.e. one tz-naive, one tz-aware

>>> pd.to_datetime(vals)
DatetimeIndex(['2011-01-01 05:00:00-05:00', '2011-01-02 10:00:00-05:00'], dtype='datetime64[ns, US/Eastern]', freq=None)

# for strings we do something more reasonable

>>> pd.to_datetime([str(x) for x in vals])
Index([2011-01-01 10:00:00, 2011-01-02 10:00:00-05:00], dtype='object')
```
This PR changes the first call to behave like the second.

2b) We also need to decide whether datetime64 are considered naive or UTC within `array_to_datetime`