Cascading of fallbacks

I took the liberty of copying a post from martin_q from #347351: Enable translation fallbacks (http://drupal.org/node/347351#comment-6891438) where he mentions cascading of fallbacks and some code cleanup.

Original psot:

Hi attiks,

Thanks for creating a 'real' project through a refactoring of my code. I never got around to doing that, and I'm glad that there is a felt need to do something with what I had started to put together. I didn't realise 'locale_custom_strings_XX' could be set using variable_set() - this is much cleaner than setting values in $conf using hook_boot(). Storing the value of the fallback language code in the object rather than separately in the variables table is also a great improvement that is made possibly by doing it this way.

You've removed the cascading of fallbacks, which would mean it would not be possible for, say, one dialect of German to be a minor variant of another dialect of German which itself is a major variant of standard German without having to fully populate both the dialects with almost identical information. Was this more of a performance or a principle based decision?

When I found myself manipulating these objects to mimic multi-dimensional arrays, I found that it was blowing both my own mind and also seemed difficult to grasp for most of the people I tried to describe it to. In particular I was asked to comment copiously on why I did things like just returning [NULL] for the offsetSet() and offsetUnset() functions in these two object implementations. Obviously it makes perfect sense to do this in this situation but people coming in and trying to understand the code might not immediately get it. So - even if my level of commenting was excessive - I'd suggest including at least a bit more explanation than is currently in the code you have written.

I'm happy to be a co-maintainer of this in D7 if needed/wanted.