Issue description: Duplication of items when Refined Storage importers are connected directly to Mekanism entangloporters.

What happens: Any item transmitted to the receiving entangloporter is accepted by the importer into the storage system, but it also remains in the entangloporter's item buffer. So the importer will just take 20-25 (at max speed) of that item indefinitely.

What you expected to happen: No duping of the item to be imported.

Steps to reproduce:

1. Set up chest and pipe/conduit/duct to transfer any item into a powered Mekanism entangloporter that is configured to send items.
2. Second entangloporter set to receive items on the same channel.
3. RS importer attached directly to the second entangloporter.
4. Send any item through via the chest, and the grid should show massive duping of that item.
   ...

Apologies if this is a Mekanism bug - I have no way of knowing which mod is responsible and took a guess.

Version (make sure you are on the latest version before reporting):

• Minecraft: 1.10.2

• Forge: 12.18.3.2422

• Refined Storage: 1.2.26

• Mekanism version is 9.2.2.fix3, in case that matters.

Does this issue occur on a server? [yes/no] Yes

If a (crash)log is relevant for this issue, link it here: N/A

• 1.10 is unsupported.
• This is most likely a Mekanism issue.

OK, thank you.

@raoulvdberge There is indeed a bug in Mekanism (the non-simulated extract method fails because of an IInventory method not doing the right thing)

However, the dupe is caused by RS (and appears the same behaviour in 1.12 would happen). Your importing code seems to insert to the RS network from only the simulate result. I think it should be doing it from the result of the non-simulated extract. Or at the very least ensuring that the result of the non-simulated extraction matches to counteract bad IItemHandler implementations, of which I've seen a few. Many simulation handling implementations short circuit by necessity - and the SidedInvWrapper from forge that Mekanism uses is one of them.