Bug 1044525 - Avoid poking with DOM elements in various modules aside from renderer by using a WeakMap to hold layout key objects, mapped from DOM elements.

- render.js's key properties normalization is now done in LayoutNormalizer. The normalization for static layouts takes place in layout loader, when the layout is loaded. Layout Manager's on-the-fly generated keys are pre-normalized in the hard-coded structures.
- Also, removed parseInt() on keycodes where suitable as we now retreive "number" from the objects held by WeakMap.

We have two WeakMaps, one maps DOM element to abstract target objects ("forward" map), and one maps inversely ("reverse" map)
Policy of accessing those WeakMaps is:
- IMERender and AltCharMenu(View) can set both forward and reverse maps by calling IMERender.setDomElemTargetObject, a small helper function.
- Everyone can retrieve forward mapping (elem to obj) in layoutRenderingManager with LRM.getTargetObject.
- Only IMERender and AltCharMenu(View) can retrieve reverse mapping (obj to elem) accessible through IMERender's reverse map (targetObjDomMap).
 -- currently we need to allow AltCharMenuManager to do so 'coz their responsibility and coupling aren't very clear.
 -- we probably need some refactoring work to reassign the responsibility and coupling such that targetObjDomMap isn't unnecessarily exposed.
Actually this is a bit related to comment 20 in the bug, what Rudy's talking about.

The additional condition is to test if we're matching the alt char menu container, for which DOM element UsrPrsMgr will fail to find a key object (so we get an empty object = what we're testing for).
Theoretically, this condition should actually results in returning true, (see the lines that immediately follow), but with the buggy implementation in current master (see comment 21 in the bug) we'll anyway be stuck at AltCharMnu.getMenuTarget's failure to retrieve the correct (i.e. last) alt char, and thus the mapping mechanism will still need to pull the plug somehow somewhere.

The canonical way to remove this testing is to correctly resolve bug 1074095 in the way discussed with Rudy offline: in ActiveTgtMgr resolution on "which key object this |press| should resolve into", we return the key object of the last alt key if we deem the press is happening in the blank area. Thus, we try not to allow handlers and logics in the "downstream" to see the container if possible -- this would make things a lot more clear.