De-dupe fills and trades from WebSocket.

[prashanDYDX]

We're seeing quite a few crashes from trying to render fills and trades with duplicate IDs. After discussing with James, it sounds like it is to be expected that duplicate messages are received over the websocket.

The main issue here is that for Processors that return a List of items, we are just appending items blindly. To limit the scope of this PR, we won't change the API signature from List to Map, but rather will use a set to ensure that only a single item with the same ID is returned.

Note: mutableSetOf() is backed by a LinkedHashSet, so ordering is preserved.

This PR addresses the two main offenders: Fills and Trades. There are other processors that have the same potential pitfall, but I will tackle these in a follow-up.

[ruixhuang]

Note: mutableSetOf() is backed by a LinkedHashSet, so ordering is preserved.

Not sure if it's safe to since the implementation can be differ on each platform, and future implementation might not maintain ordering. Might as well just keep the ids in a set, and appending the old to new if id is not in the set.

[prashanDYDX]

Note: mutableSetOf() is backed by a LinkedHashSet, so ordering is preserved.

Not sure if it's safe to since the implementation can be differ on each platform, and future implementation might not maintain ordering. Might as well just keep the ids in a set, and appending the old to new if id is not in the set.

I think it's pretty safe to assume that LinkedHashSet will continue to provide ordering. LinkedHashSet itself is in the Kotlin stdlib, this isn't just the JVM implementation. And changing the default of mutableSetOf() to a different set implementation seems like a pretty drastic breaking change.

But managing the IDs on their own does let us avoid the map at the end, so I'll do that.