* Add `size` to setIndexBuffer/setVertexBuffer.

If `size` is zero, the size of the {{GPUBuffer}} is used. (Binding a subset instead of the
whole buffer allows for concurrent use of other parts of the buffer)

This potentially opens the door to mapping subsets of otherwise in-use buffers.

* Remove in-spec comment speculating on sub-range validation.
* `size=0` => remaining size *after offset*.

* Add `size` to setIndexBuffer/setVertexBuffer.

If `size` is zero, the size of the {{GPUBuffer}} is used. (Binding a subset instead of the
whole buffer allows for concurrent use of other parts of the buffer)

This potentially opens the door to mapping subsets of otherwise in-use buffers.

* Remove in-spec comment speculating on sub-range validation.
* `size=0` => remaining size *after offset*.

- Added descriptions to all tests
- Fixed naming where appropriate
- Added more test cases to the viewDimensions test.

<hr>

**Author checklist for test code/plans:**

- [x] All outstanding work is tracked with "TODO" in a test/file description or `.unimplemented()` on a test.
- [x] New helpers, if any, are documented in `helper_index.md`.
- [x] (Optional, sometimes not possible.) Tests pass (or partially pass without unexpected issues) in an implementation. (Add any extra details above.)
    
**[Reviewer sign-off](https://github.com/gpuweb/cts/blob/main/docs/reviews.md) for test code/plans:** (Note: feel free to pull in other reviewers at any time for any reason.)

- [x] The test path is reasonable, the [description](https://github.com/gpuweb/cts/blob/main/docs/intro/plans.md) "describes the test, succinctly, but in enough detail that a reader can read only the test plans in a file or directory and evaluate the completeness of the test coverage."
- [ ] Tests appear to cover this area completely, except for outstanding TODOs. Validation tests use control cases.
    (This is critical for coverage. Assume anything without a TODO will be forgotten about forever.)
- [x] Existing (or new) test helpers are used where they would reduce complexity.
- [x] TypeScript code is readable and understandable (is unobtrusive, has reasonable type-safety/verbosity/dynamicity).