FIX: to_sql takes the boolean column as text column
In the original code, `com.is_bool(arr_or_dtype)` checks whether `arr_or_dtype` is a boolean value instead of a boolean dtype.

A new function `is_bool_dtype` is added to `pandas.core.common` to fix this bug.

@yelite Thanks for the contribution!

Can you add a test for it (look in io/tests/test_sql.py)? You can for example take the example you were working with where you experienced the issue, and slim this down to a small test case. Just ask if something is not clear for this.

@jreback There isn't already a function like this somewhere?
 this is already in master (recently added)
core/common iirc
 @yelite indeed, it is already here: https://github.com/pydata/pandas/blob/master/pandas/core/common.py#L2255
 @jorisvandenbossche 
Great, I removed my function from the commit and added a simple test.
 @yelite I wanted to say your test would fail because of the index, but you already adapated it!

Can you add a line in doc/source/v0.14.1.txt in the bug fixes section for this?
 @jreback 

```
AssertionError: attr is not equal [inferred_type]: 'string' != 'unicode'
```

https://travis-ci.org/pydata/pandas/jobs/29317980

Does this difference between `string` and `unicode` really matter? Should we omit it?
 so the returned data is unicode. so 2 solns:
- on the test calls tests with (and w/out) the server returning unicode (IIRC they usually and by default do, but can be turned on/off 

e.g. in sqlalchemy (sort of manuall), I usually do

`engine.dialect.description_encoding=None` (with postgresql),
- add an option to `assert_frame_equal` to ignore this different (better soln I think)

@jorisvandenbossche ?
 @jreback 
A mistake. I thought `check_column_type` means checking the type of each column. Actually it checks the type of column block. So it's not important in this test. I set it to False now.

@jorisvandenbossche 
I added a line at the end of  `doc/source/v0.14.1.txt`. Is that ok or it should be organized by section?
 For the whatsnew note, that is OK.

And the column names of the original dataframe and the result from `read_sql` are indeed different in type ... (but indeed, not important to test that here). 
 Travis is green, so merging. 
Thanks a lot! (and if you want to tackle other issues, don't hesitate :-))
 https://travis-ci.org/pydata/pandas/jobs/29341707

I have seen this happen if something weird is passed to an `is_***_dtype` (`np.dtype` craps out).

let's see if it repeats
 hmm, the next travis builds have the same (but strange that for the PR it had not this issue)
