BUG: Fix inconsistent C engine quoting behaviour
1) Add significant testing to quoting in `read_csv`

2) Fix bug in C engine in which a NULL `quotechar` would raise even though `quoting=csv.QUOTE_NONE`.

3) Fix bug in C engine in which `quoting=csv.QUOTE_NONNUMERIC` wouldn't cause non-quoted fields to be cast to `float`.  Relevant definitions can be found in the Python docs <a href="https://docs.python.org/3.5/library/csv.html">here</a>.

I think that we should expose these `csv.QUOTE_*` values somewhere in the pandas namespace as well. and/or, maybe accept a string? e.g. `quoting='QUOTE_NONE'` ? (and case_insensitve), or maybe just `quoting='nonumeric','minimal','all'` (not really even sure what `QUOTE_NONE` does)

not sure if this is an issue in the real-world, but seems to be a small pot-hole.

@jorisvandenbossche 
 @jreback : Documentation on the meanings of the `csv.*` enums can be found in the link I provided in the initial PR description.
 @jreback : I'm perfectly fine with name-spacing as I just commented <a href="https://github.com/pydata/pandas/pull/13411#discussion_r66445182">above</a>, though I'm hesitant about accepting strings.  IMO enums are sufficient and will make it easier for users to debug (spelling errors).

Not entirely sure how many people use them as you said (my guess is that many don't, and I certainly have never used them in my work), though it should probably remain as an option since it does play a role in `csv.Dialect` creation.
 ## [Current coverage](https://codecov.io/gh/pydata/pandas/pull/13411?src=pr) is **84.32%**

> Merging [#13411](https://codecov.io/gh/pydata/pandas/pull/13411?src=pr) into [master](https://codecov.io/gh/pydata/pandas/branch/master?src=pr) will decrease coverage by **<.01%**

``` diff
@@             master     #13411   diff @@
==========================================
  Files           138        138          
  Lines         51069      51068     -1   
  Methods           0          0          
  Messages          0          0          
  Branches          0          0          
==========================================
- Hits          43066      43065     -1   
  Misses         8003       8003          
  Partials          0          0          
```

> Powered by [Codecov](https://codecov.io?src=pr). Last updated by [013c2ce...bf2a59e](https://codecov.io/gh/pydata/pandas/compare/013c2ce760083e5454552ad44bba8d2f44da2caa...bf2a59eb9398bf60d6bc35a4619730c6c7472082)
 Added the `io.common` enums, and Travis is still happy.  Ready to merge if there are no other concerns.
 I am not really sure that I find `pd.io.common.QUOTE_` better than `csv.QUOTE_..` (but it is one import less, that is true). 
I would maybe rather accept strings like `'minimal'` or `'nonnumeric'`, this seems the more user friendly option? (but it makes it of course more verbose to explain all possibilities in the docstring)
 @jorisvandenbossche : I disagree about the strings.  See my reasoning <a href="https://github.com/pydata/pandas/pull/13411#issuecomment-224904178">above</a>.  The inclusion of the enums in the namespace was to avoid hard-coding them as I did initially in `parsers.pyx`.
 @jreback : Did some minor tweaking of the docs once more to mention that the `csv` enums can be found in `pandas.io.common`.  Ready to merge if there are no other concerns.
 > I disagree about the strings.

OK on not adding those, but still, I don't see the added value to users of having the enums in pandas.io.common (it's just more ways to import the exact same thing). So personally I would just not mention it in the docs (also, if we do put it in the docs, we should have a test for it)
 What test exactly?  Not sure what you mean.  @jreback thoughts?
 > What test exactly? Not sure what you mean

Sorry, I meant just a simple test that it is available in the pd.io.common namespace (if we want users to use it from there). But let's first decide what to do with it.
 @jorisvandenbossche : Not sure if we're encouraging users to use it from there.  Just providing a `pandas`-namespace location where those enums are available from what it seems.
 > Not sure if we're encouraging users to use it from there. Just providing a pandas-namespace location where those enums are available from what it seems.

Adding it to the docstring seems 'encouraging users to use it' to me, why otherwise adding it there? For me it's OK to add it to the pd.io.common namespace if that makes the implementation easier, no problem, I personally would just not add it to the documentation. 
@jreback do you have any preference?
 I could go either way. I thought it would be more consistent, IOW, a user can just use it directly, not having to think about `csv` module at all. Though since we don't really document these completely, maybe should just back it out and point for all of this to `csv` module (for the constants).

So @gfyoung let's revert that (the location of the constants).
 thanks @gfyoung 
 @gfyoung Thanks a lot! This more comprehensive testing is really good
