FIX str.match uses na flag
fixes #6609

travis failing is a refused connection with fred, unrelated to this pr (you'd think)

https://travis-ci.org/pydata/pandas/jobs/20585139
 hmm are the Fred calls wrapped with network. decorator?
that should catch and skip those tests
 actually these network errors are 'ok'. because in theory if the URL had changed that's what we'd get 

so if it keeps repeating....can investigate further
 I was wondering, should it be noted in the docstring that by default it gives NaN for non-strings? (because you could also assume this gives False)
 @jorisvandenbossche this fix makes it inline with the current behaviour of contains (et al?), I guess we could change the docstring too (not sure which others this is used in).

...tbh I had assumed that it was equivalent to s.astype(str).str.contains(...) but they aren't (i.e. you can't search for digits of a number).
 (re fred, this branch passed on hayd/travis, so it's something intermittent)
 @jorisvandenbossche I kind of think I should merge this in first, then have sep issue for the docstring. Maybe adding it to docs example of vectorised string methods would be enough...

Oh goodness, when I implemented `get_dummies` I used `.astype(str)` to get around this problem, I had assumed this was how they all worked... I suspect that's going to raise sometimes? :s
 Yeah, but I would certainly add something to the docs, since you also expected non-strings to be converted to strings instead of giving NaN.
 For further discussion see also #6634
 What's weird is that I'm still convinced I'd tested it (on the other methods)!
