Adding True _() Syntactic Sugar to NGettext

[c4tachan]

This PR adds some syntactic sugar to the NGettext implementation.

It allows you to initialize and use a default Catalog that can then be accessed throughout your software by simply prefixing strings with _() (no catalog object instance required)

Contextual and Formatted strings are accessed by adding c and/or f after the _

eg.

using static NGettext.NGettext;

namespace project
{
    public class program
    {
        public void main()
        {
            string imLocalized = _("Localize Me!");
        }
    }
}

This behavior relies on using static <fully qualified class name>

The current implementation uses a static class, but it might be worth while to convert the static class into a singleton.

Unfortunately, I haven't been able to get the NGettext Solution to compile on my machine, however I have gotten this static class to compile in another project I was working on that uses the existing NGettext nuget packages, so while I am not going to give up on compiling it, I would like others to get a look at what I've done.

[VitaliiTsilnyk]

Thank you for the PR but I'm afraid I can't accept it. It would be incompatible with COM/CLS (you even have a compiler warning suppression for that), but we need this to support some older platforms.
Also, this implementation limits to the use of one specific loader .

But nice idea though. I didn't think about it.
We have a short syntax example, which you can add to your project and modify to your needs. And its compatible with your solution, you can just import it with using static and it would work basically identically to yours.
I'll extend the readme to describe how to use it with using static.

[c4tachan]

How married are you to complete CLS and COM compliance?

One way to implement this, without destroying the COM/CLS compliance of the main NGettext package would be to add non-compliant wrapper DLLs that are targeted for a specific language (eg. NGettext.CS, NGettext.VB, etc.).

[VitaliiTsilnyk]

Yeah and we're doing something like that already. Theoretically if you define proper precompiler directives to include this code only on modern targets, it will work.
But still I don't want to bring something like that into the project directly for multiple reasons, for example:

1. Calling a single static translation catalog is not very nice in terms code design (most people would probably prefer loading it via an IoC container).
2. It fits some small projects and it gives you a nice C-style gettext syntax, but you won't be able to do that if you use multiple locales in a single application instance (like in a server application for example).
3. And as I already said, it forces you to use one specific loader. It would require much more work to make it as flexible as the main catalog implementation.