Added optional Culture parameter to DateTime.Humanize

I've implemented optional Culture parameter for DateTime.Humanize + updated unit tests to check both explicit & implicit Culture cases.

Please check it, and if it's okay for you, i will proceed with adding Culture parameter to other Humanizer's methods.
I agree that creating a new object is probably cheaper then using Lazy<>. Especially, in a multithreaded application. But garbage might be a problem.

"as it is really-really cheap operation (we basically do not have any initialization logic)"

Well, this is true about current formatters. But, are you sure that always will be the case? Plus, this logic lives in LocaliserRegistry base class, which is also used by NumberToWordsConverterRegistry class and by some others. Are we sure that all those have very cheap constructors and will always have?

Actually, question here is if we really need all this complication and is not just passing "culture" parameter does the trick w/o introducing additional concerns.

About this: 

"Indeed, the formatter is retrieved with the notion of the culture already so it should know about the culture to use.
In other words it's an implementation detail of one particular implementation of the IFormatter interface and not a part of its input."

I'm not quite agree here. From my point of view "culture" is not a part of formatter's implementation. It's completely valid for a formatter to be able to serve different culture. Look at CzechSlovakPolishFormatter, for example. Formatter just defines rules, which may apply to several languages. That's why i think it's completely valid to pass "culture" as a parameter to the formatter's methods.