sql: don't include quotes in parsed strings

[dt]

The planner.TypeAsString* helpers, currently only really used in backup/restore/import, were using
parser.AsStringWithFlags to get the string value of the expr they retured. However even in 'bareStrings'
mode, this still prints non-trivial strings in quotes. If calling code is planning to use the value of
the string, for instance as a URI or parameter value, mangling it with added quotes is almost certainly
not desired. These helpers are used to read params from a query for processing, not print parsable SQL.

[cockroach-teamcity]

This change is 

[dt]

I understand how the backup unit tests didn't catch this with their tidy file path params that didn't trigger quoting, but i'm not sure how we didn't catch this trying to use cloud URIs? but out cloud store URIs were working too since they didn't include comma or spaces so far.

[knz]

---

Reviewed 3 of 3 files at r1.
Review status: all files reviewed at latest revision, all discussions resolved, some commit checks failed.

---

Comments from Reviewable

[dt]

TFTR!

[benesch]

Heh, that call to parser.AsStringWithFlags always struck me as suspicious. Nice catch! If you find yourself in the area again, would be nice to have a comment about why the space is important so it doesn't get refactored away.

[dt]

Yeah, a unit test on planner.TypeAsString* would be ideal -- I was just wanting to get a quick fix though so I could try another prod test.