[PRO-444] Add support for missing websocket fields

[justinpolygon]

I added support for the ds, dv, dav, and pt fields, which the server sends
but our websocket models were missing. Go ignores JSON fields it does not
know about, so we were quietly throwing this data away.

The main one is ds. It holds the trade size when someone buys part of a
share. Our Size field only holds whole numbers, so a trade of 0.85 shares
came through as 0, which looks the same as a trade of nothing.

I checked this against the live feed for 30 seconds. Out of 79,479 stock
trades, 3,045 were smaller than one share and every one of them read as 0
before this change. Options does not send these fields, and 18,574 options
messages still decoded correctly with them left empty.

All four fields are new, so nothing breaks. REST already had this data
because it is generated from the API spec, but the websocket code is written
by hand so it was missed.

[lukeoleson]

This looks good - one question though:

The ticket says that we could consider adding methods like AsPrecise() or AsFloat() - I think that is suggesting doing something like a custom type with methods on it that the user can use to get this either as a string (with precise decimals) or a float64 (with possible precision loss).

I just wanted to make sure we decided against that approach as once we ship these fields as strings we won't be able to take them back.

I think this makes sense tbh. If we did make a custom type with those methods, users who want precision would still end up with a string that they have to handle themselves to get the precise value as a number they can do math with, so it's not real boon for them. And users who don't want precision will just have to do a ParseFloat(), which is easy enough. So I think this approach is probably better imo - just wanted to double check :)