Follow-up to #1999.

Right now if you want to create a buffer that isn't a multiple of 4 bytes, the last 1-3 bytes can't be accessed by mapping:

• using mappedAtCreation makes the createBuffer call invalid
• mapAsync with the default size fails, so the size must be specified explicitly at a different size

So, what if we just:

• allow the end of a mapAsync/getMappedRange to go past the end of the buffer, to the next multiple of 4
• round up the default mapAsync size (undefined) and the mappedAtCreation range to that

TBD what the exact semantics of those 1-3 padding bytes should be. Probably they persist in the mapping shadow allocation, but validation prevents them from ever being used by anything else. However we could potentially also allow copyBufferToBuffer to access those bytes if we also wanted to polish off that rough edge (mentioned in #1999).