i18n: move YARD::CLI::I18n::* to YARD::I18n::*

[kou]

Those changes are corresponding to 1. and 3. in #395:

#395 (comment)

1. I'd like it if you could move your CLI::I18n subclasses into a
   YARD::I18n namespace. I'm not a fan of classes inside of classes,
   organizationally speaking, and it's hard to promote component reuse
   for these classes if they're inside of a CLI namespace. Presumably
   someone might want to use the PotGenerator class directly, for
   instance, and they shouldn't have to go through the CLI. So, I've
   marked those classes as @private for now so that nobody uses them
   from that namespace. Once you move them into a more appropriate
   location, you can remove the @private declaration and we can support
   them as a public API.
2. ...
3. Ditto for moving the tests for the inner classes like
   PotGenerator and Test into their own files. I'm also not a fan of
   multiple classes in a single _spec.rb file.

[lsegal]

Thanks! We landed this just in time for 0.8.0.

One thing I noticed after you documented the code is that PotGenerator#messages has a very long type signature. To me, this usually implies that the API is equally complex to use. The type: Hash{:locations => Array<Array[String, Integer]>, :comments => Array<String>} to me screams of refactoring into a separate class with .locations and .comments attributes. That way we can have a properly documented Message (would this be the right name? or PotMessage?) class component that has meaning in our system, and #messages would turn into Hash{String=>Message}, which is much clearer to me. Can you do this refactor?

No rush on this one, I'm not expecting it for 0.8.0, since we are releasing today, but we can target 0.8.1. I've marked the #messages API method as "private" (with @api private) for now to notify users that we are going to change this slightly.

[kou]

Thanks for merging!
It's great news that 0.8.0 ships a I18N feature!

I'll do the refactor after 0.8.0 is released.