Respect 'key' prop for object identity

[sophiebits]

Now when a key prop appears, its value is always honored. This means that in the root component or as an only child, changing key will cause remounting; in a children object, the key prop will be joined with the object key to form a two-part key.

Fixes #590.

cc @ide

[sebmarkbage]

The current semantics of keys is that they're only used to identify components within an array, as a convenience to avoid creating a keyed object fragment. They're not general purpose state breakers.

It might make sense to change the semantics to general purpose state breakers since it's kind of confusing that this honors the key:

var child = <StatefulComponent key="foo" />;
return <div>{child}</div>

But this doesn't:

return {child}

Which makes it a refactoring hazard. In that case it should probably use the key of the component in the position of an object fragment. E.g. this should also respect the key of the object position AND the child's key (the effective resulting key would be {bar}{foo}).

return { bar: child };

@jordwalke This type of keying convention, of putting values on the props, can completely avoid the deoptimization problem since there is no need for these keys to ever go on a flattened children object, as your linked-list implementation shows.

[jordwalke]

@sebmarkbage : But they go on an object, which appears to be enough to cause the optimizer to go into a tailspin.

[sophiebits]

@sebmarkbage Seems reasonable, done.

[zpao]

@sebmarkbage Can you handle reviewing and syncing this one?

[petehunt]

The way you treat index here rubs me the wrong way... if you do it this way I believe you're baking additional assumptions about the caller of this function (that it's called on two components in the same position). While that was true before it seems like a bit of a weird assumption to bake in, no?.

Can you change getComponentKey() to look at _mountIndex or does that break stuff?