add `._shapeId` to shape generating futures

[tmpvar]

after the change in net-oce to allow js to generate shapeIds (solids/net-oce@eb7c660b76461c72c174c4638f3a9512f3ffdd11), the change in net-oce-protocol to both add an optional shape_id to NetOCE_Requests (solids/net-oce-protocol@75a2a7fd53ef992daeae35b6e9712a3ea5c4b3d9) and the change to add the shapeId to the request (solids/net-oce-protocol@f4ff4ad30d57af94b0cb86b52668d9bcfc2d5f82) we can now start removing the network round trips as a bottleneck

This commit sets up a future._shapeId on all shape generating methods and immediately resolves them with the appropriate shapeId. This is then passed to net-oce-protocol to be pushed to net-oce which will process each request serially.

Example

display(cube(10).cut(box(5, 10, 100))

gives us a dependency tree that looks like

                 .- cube(10)
display <- cut <-
                 ' - box(5, 10, 100)

which gets processed like

1. cube(10)
2. box(5, 10, 100)
3. cut({id : 1 }, { id: 2 })

This results in local speeds like:

vs master which looks like:

We can probably go faster if we simply do not respond to shape creation operations, and by amortizing display to stream objects in and have them added to the scene one at a time instead of having to process hundreds at a time.