Move dictionaries to i18n

No, I'm talking about the different branches that the code can take. What we currently have says there are 2 (and one it block floating?) contexts: with text only, and with the :notfound option. That's not true, because within the text only, there are different contexts that are hidden by the it block containing them. Within text only, we have when the text is not found in the lookup, when the text is a column entry, when the text includes a '\__', when it includes a '.' and a '\__', and finally when it is a nested key. I would consider these all separate contexts. Also, the it block by itself should be a context "when there is a :type option".

There's currently 5 if statements (including an unless and a ternary), and within two of those, there's a ```&&```. Two of those actually return early as well. That sounds like a lot of contexts to me.

I guess what gets me is that if you're using contexts with no set up in them, why are we even using contexts? This test could just as easily have been written with a bunch of it blocks all at the same level. The context should define what makes that context different, via either ```before do```s or ```let```s.

Otherwise, sure, this *looks* clean, but I would argue bad practice:
```ruby
describe Dictionary do
  context ".gettext" do
    it("works when text not found") { expect(described_class.gettext("abc")).to eq("abc") }
    it("works with a column entry") { expect(described_class.gettext("active")).to eq("Active") }
    it("works when the text includes '__'") { expect(described_class.gettext("active__abc")).to eq("Active (Abc)") }
    it("works when the text includes '.' and __'") { expect(described_class.gettext("prefix.active__abc")).to eq("Active (Abc)") 
    it("works with a nested key") { expect(described_class.gettext("availability_zone.total_vms")).to eq("Total Instances") }
    it("works with :type option") { expect(described_class.gettext("FileDepotFtp", :type => "model")).to eq("FTP") }
    it("works with :notfound, and plain text") { expect(described_class.gettext("abc",     :notfound => :titleize)).to eq("Abc") }
    it("works with :notfound, and '.' in text") { expect(described_class.gettext("abc.def", :notfound => :titleize)).to eq("Def") }
    it("works with :notfound, virtual column, and plain text") { expect(described_class.gettext("v_abc",     :notfound => :titleize)).to eq("Abc") }
    it("works with :notfound, virtual column, and '.' in text") { expect(described_class.gettext("abc.v_def", :notfound => :titleize)).to eq("Def") }
  end
end
```

I think separating it and it being more confusing is actually OK here...because like I said before, it shows you something is up. Yes, it's more confusing, but instead of hiding that away, you can take that as a "hmm, well, maybe this code should be refactored" instead of bending the spec to fit the code.

Now, this seems like something pretty low level that we could likely stub out in other places to give us a canned result and that we would use a lot, so, I would much prefer every single context be tested thoroughly.