Combine components under Localisation namespace by language rather than by component type

[hazzik]

/Humanizer/Localisation/

/Humanizer/Localisation/ar/ArabicFormatter
/Humanizer/Localisation/ar/ArabicNumberToWordsConverter

/Humanizer/Localisation/ru/RussianFormatter
/Humanizer/Localisation/ru/RussianNumberToWordsConverter
/Humanizer/Localisation/ru/RussianGrammaticalNumber
/Humanizer/Localisation/ru/RussianGrammaticalNumberDetector

etc

[hazzik]

Related to #59

[akamud]

@hazzik, I looked into your issue-206 branch, it looks like you already finished this. Is there something else that needs to be done or are we just waiting for V2?

[hazzik]

just waiting

[MehdiK]

There were a few confusions are how we wanted to do it. IIRC we couldn't find a win-win situation and there was always a compromise. I am still not 100% convinced which way is better tbh.

The PR will also have to be updated with the later localisation additions.

[clairernovotny]

Is this still in scope for v2? I'd like to get a beta out by the end of the month as the current dev branch adds CoreCLR support.

[MehdiK]

When we were discussing this solution layout, I have very vague recollection but from the memory some things didn't quite fit into the proposed solution. Not that they do in the current structure but I guess my point is that this solved one problem and introduced another one. So I'm torn on it. I'd vote to keep it as is if we don't have a strong argument for this structure. Thoughts?

[clairernovotny]

I don't have any strong thoughts on this. There's something to be said for both sides. As far as I can see, aside from the interfaces/abstract base classes, the actual localization implementations are all internal, so moving it around should not be a breaking change.

[clairernovotny]

I'm closing this out, leaving things as-is for now. We can revisit if there's reason to later.