add `._shapeId` to shape generating futures

after the change in `net-oce` to allow js to generate `shapeId`s (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: 

![screen shot 2014-11-03 at 2 43 04 pm](https://cloud.githubusercontent.com/assets/46673/4889193/bd96a010-6393-11e4-910f-e5a2da061353.png)

vs master which looks like:

![screen shot 2014-11-03 at 2 59 30 pm](https://cloud.githubusercontent.com/assets/46673/4889235/f7ec6344-6393-11e4-8210-9339ce31f73d.png)

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.