Option disable literal strings

[girlpunk]

In some environments, such as Dynamic LINQ (System.Linq.Dynamic), literal strings are not supported. As such, an option to disable generating code using these would be useful.

[EamonNerbonne]

I think the term "verbatim" is more conventional here than "literal". At first glance this looks great. I'll have time to look at this in more detail on thursday (the 25th). Thanks for the contribution anyhow!

[girlpunk]

I've seen people use "verbatim", "literal", and "raw" strings in various places, iirc there was already some parts of ExpressionToCode referring to them as "literal", so went for consistency, but I'm happy to get that changed if you'd like

[EamonNerbonne]

Yeah, it's not just this code. I'll rename that.

Incidentally, I'm currently debating whether I want to release this as-is, or clean up the API. Because one thing that isn't new in thie PR, but is more prominent after this PR is the existance of a public IObjectStringifier. However, in practice, this is just a slightly complicated way of changing the config: it'd be nicer to simply have properties such as this one, but also such as the option to always use fully-qualified type names on the plain config object, and to have that be a record so the "new" with syntax works naturally.

The old design was motivated mostly by the lack of a language feature like records, and by the practicalities of making full-type-name-qualification configurable (in #42). But it's a bit messy.

On the other hand, breaking changes in libs are annoying.

If you want to build on the change in this PR, I could always release a 4.0.0-preview1 version or whatever; that way it's immediately usable without being a default upgrade target for other users, and then I can figure out how best to make that trade-off between a clean API and avoiding breaking changes.

If you have any opinion on the API, feel free to mention em ;-).