Material-ui: [core] Remove Object.assign replacement of simple-assign

[newoga]

This is a reminder issue to at some point remove babel-plugin-transform-replace-object-assign and simple-assign. I just tested the docs site with my current version of Chrome (49.0.2623.110) and it doesn't seem to have the same style issues we had in the past with Chrome's broken implementation of Object.assign as it related to key ordering.

It's probably a little too early to remove it now since the fix was just recently released and there's a good number of users that still have Chrome 48. But I think we should be able to do it soon.

Related to #3124, #2986

[owencm]

For what it's worth, unless it's causing excessive maintainability issues I'd recommend keeping the code for Chrome 48 and before for 6 to 18 months since mobile devices in emerging markets especially have a very slow rate of updating native apps. If developers want to use MUI in production in a country like India we'll need to maintain this support for a good amount of time.

[newoga]

Thanks for feedback, @owencm! We'll definitely keep that in consideration. I don't think this is a major burden from a maintainability standpoint. I just wanted to document this because the casual onlooker (and even contributor) might not understand what the motivation was behind implementing the transform in the first place.

I know React recently merged a PR (https://github.com/facebook/react/pull/6376) that replaced their own Object.assign implementation with object-assign which uses the browser implementation when available. Though maybe they are not using it in a manner where key order counts.

[newoga]

Just an update on this, we could probably consider using the object-assign ponyfill again because they just merged a change that checks for the "order of keys bug" in the native implementations and overwrites it if it exists.

I suppose the disadvantage is potentially a small one-time runtime penalty of doing the test (inconsequential in my opinion), in exchange for the advantage of using possibly optimized native implementations provided that they are working properly.

This isn't super high priority but I think if we can confirm it's working, it'd be worth swapping out to simplify and reduce our build/build dependencies.

https://github.com/sindresorhus/object-assign/pull/32

[oliviertassinari]

I think that we can remove it on the next branch now. From can-i-use data, the relative usage of Chrome 48 is 0.03%. Also, I don't think that we rely on the key order anymore on the next branch 👍 .