Objects indexed by integers get reordered upon serialization

[Itms]

By reverting r16929 and running the attached commands.txt, a serialization error happens.

The diff of OOS dumps is attached. The failing turn is the one when the item 159 is added.

This is probably the cause of #2863 and #3133.

[Itms]

In 16929:

Revert r16591.

The problem caused by nested Maps is actually #3374.
Cloning the data object saved by the AuraManager fixes #3188.
Also, using Map fixes a serialization problem, refs #3375.

On top of those changes, some reordering of add/multiply to avoid any ordering mistake.

Fixes #3164, Refs #3374

[Itms]

Here is a test that reproduces the problem: ​http://pastebin.com/A4RCbQzC

[leper]

I suspect this has something to do with adding elements in a way that produces something that is seen by SpiderMonkey as a dense subset of some elements, thus triggering the first ​https://mxr.mozilla.org/mozilla-central/source/js/src/jsiter.cpp#141 loop, which ends up reordering part of the properties of the object.

I'm not entirely sure if we can prevent that, and also not why the original state does not have the reordering. We should possibly try not to use integer indexed identifiers in objects, but use Map instead.

[sanderd17]

In 17935:

Change an Object into a Map, this should stop the deserializer of reordering the keys in some cases and stop an OOS on rejoining. Refs #3375