client: add a mir_surface_spec_set_buffer_stream() and mir_surface_spec_set_presentation_chain() function that's capable of arranging both MirBufferStreams and MirPresentationChains within the MirSurface.

This solves:
1) How to create a MirSurface with the NBS stuff at its start
2) How MirPresentationChains can scale in X/Y directions (similar to how MirBufferStreams scale)
3) How to mix and match MirPresentationChains with MirBufferStreams in one multi-stream MirSurface, if the user wishes.
4) What the display-size of a MirPresentationChains with multiple physically-sized buffers will be.
5) Allows for one PresentationChain to be displayed in different MirSurfaces, with flexibility in their scaling.

I had to think a bit about how we define our sizes to get to this point, but I think its coherent:

MirSurface sizes are set by the shell. When the shell decides to resize the client it sends the mir surface resize event. The size of their component contents (stream/chain) are something left up to the client, with sensible defaults. If the client has deviated from the default, it must manage the resize event and rearrange its composition and streams to fit within the size given to it by the server/shell.

MirPresentationChains display size are set by the client when they're associated with a MirSurface. The physical sizes are plainly the size of the MirBuffer. MirPresentationChains don't intrinsically have sizes in-and-of-themselves, as they're really just a bunch of buffers.

MirBufferStreams let the mir code manage their own physical and virtual sizes. The physical and displayed sizes largely change together by action of the server (legacy behavior), but setting scale and resize events can cause persistent or temporary differences between the two.

Approved by Andreas Pokorny, Chris Halse Rogers, mir-ci-bot, Cemil Azizoglu, PS Jenkins bot.