[corlib] Don't throw exception for null locale to fix threadpool-exceptions5.exe...

[corlib] Don't throw exception for null locale to fix threadpool-exceptions5.exe hang

We were seeing persistent hangs in the threadpool-exceptions5.exe test on the Jenkins ARM machines.
Tracing the execution showed the following exceptions:

```
[0x7f65e3284700:] EXCEPTION handling: System.Threading.ThreadAbortException:
[0x7f65e3284700:] EXCEPTION handling: System.Exception: From OnCBFinished
[0x7f65e3284700:] EXCEPTION handling: System.ArgumentNullException: Value cannot be null.  <-- from CultureInfo.CreateSpecificCulture()
Parameter name: name
[0x7f65e3284700:] EXCEPTION handling: System.Threading.ThreadAbortException:
exception inside UnhandledException handler:

... program hangs here ...
```

It turns out that the machines don't have the LANG/LC_ALL env vars set, resulting in a null string returned
from get_current_locale_name(). The code then tries to construct a locale from that and throws an ANE which is
normally catched and turned into the InvariantCulture.

However, in the threadpool-exceptions5 test the first time a CultureInfo is created is in the OnUnhandledException
event handler when calling ToString(). This means that an exception is thrown while we are in the unhandled exception
handler and the runtime apparently just stops there (despite the exception actually being catched, probably because of
the thread abort) so we never get to signaling the monitor object -> we hang in Main().

The fix is to not rely on catching the ArgumentNullException when we get a null locale, which is a better approach anyway.

To easily reproduce the issue before the fix, use the following (on Linux only, we don't use LANG for locale on OSX):

```
~/dev/mono/mono/tests$ LANG=C MONO_PATH=../../mcs/class/lib/net_4_x/ ../mini/mono-sgen --trace=N:nothing threadpool-exceptions5.exe
```

Note: If you pass an invalid LANG=foo, the hang is still there as we throw a CultureNotFoundException and hit the same issue.
As the behavior looks like a runtime bug to me I filed https://bugzilla.xamarin.com/show_bug.cgi?id=37547