feat($q): add streamlined ES6-style interface for using $q

This potentially helps lead the way towards a more performant fly-weight
implementation, as discussed earlier in the year. Using a constructor means we
can put things in the prototype chain, and essentially treat $q as a Promise
class, and reuse methods as appropriate.

Short of that, I feel this style is slightly more convenient and streamlined,
compared with the older API.

Related to #6427

(This doesn't do what was requested in #6427, however I feel it's a better
solution as it looks similar to the newer native Promise implementations becoming common
in the web platform).
These assertions were just used for debugging, it would be helpful to keep them but they probably won't look like this.

The promise-proxying strategy of Bluebird is a keeper, I think. Promise$$cast and $$proxyPromise have been helpful.