Bitmap image data type
Writing down yet another somewhat frequently requested feature: ability to mark up 2D bitmap images in some better syntax than just raw bytes (i.e. `size: ...`). Technically, it's a good idea. It's more or less obvious that all (uncompressed) bitmap images have lots of things in common:

* they all have width and height (usually derived from other attributes nearby)
* they all have some sort of pixel format
  * it's either a reference to a palette (and thus we need to provide that palette)
  * or it's a direct RGB color specification like 24-bit RGB, or 32-bit RGBA,
  * or some more obscure encoding like 16-bit 5+6+5 RGB, or YUV422, or stuff like that)
  * or even something much more obscure, such as
* they might have some sort of intricate packing specifics:
  * for example, Windows .bmp file format lists rows from bottommost to topmost, and so do some OpenGL applications due to default OpenGL axis orientation
  * another example is planar composition, which can be pretty complex as well

Note that we totally *do not* touch a question of compression: it should be solved with `process: ...`, not here.

## Draft of proposed spec

Naive proposal dictates something like that:

```yaml
- id: w
  type: u4
- id: h
  type: u4
- id: bitmap
  type: bitmap
  width: w
  height: h
  pixels: bgr565
```

or, for paletted image:

```yaml
- id: w
  type: u4
- id: h
  type: u4
- id: pal
  type: palette
  colors: 256
  pixels: rgb888
- id: bitmap
  type: bitmap
  width: w
  height: h
  pixels: index8
  palette: pal
```

This yields two new KS datatypes: `palette` and `bitmap` (actually, `palette` is more or less the same as one-dimensional `bitmap`)

## Implementation

Of course, implementation is a huge question and probably it would be better done as some sort of plugin system. Things that were cited in various discussion for now:

* C/C++ has [SDL](http://libsdl.org), which has [SDL_Texture](http://wiki.libsdl.org/SDL_Texture) class that abstracts operations with bitmap images, such as loading a bitmap with particular width / height / pixel format / planarity settings. The most interesting thing is probably [SDL_PixelFormatEnum](http://wiki.libsdl.org/SDL_PixelFormatEnum), which has ready-made answers to many pixel format questions.

* C/C++ raw OpenGL programming reads image into uncompressed raw byte array and then does something like that:

```c
glTexImage2D(GL_TEXTURE_2D, 0, GL_RGB, width, height, 0, GL_RGB, GL_UNSIGNED_BYTE, data);
```

Here, `GL_RGB` and `GL_UNSIGNED_BYTE` specify pixel format / packing. Probably we could provide some better interface here as well.

* C++ with Qt has [QImage](http://doc.qt.io/qt-5/qimage.html#QImage-3) which allows construction of image from arbitrary `char *` specifying a [Format](http://doc.qt.io/qt-5/qimage.html#Format-enum). Nothing too fancy there, though.

* Desktop Java has awt, which has [Raster](http://docs.oracle.com/javase/7/docs/api/java/awt/image/Raster.html), which allows creation of usable bitmap image from a DataBuffer, given a pretty intricate pixel format spec / planarity using [SampleModel](http://docs.oracle.com/javase/7/docs/api/java/awt/image/SampleModel.html).

* Java on Android has [Bitmap](https://developer.android.com/reference/android/graphics/Bitmap.html) and [Bitmap.Config](https://developer.android.com/reference/android/graphics/Bitmap.Config.html) which play roughly the same role. Also there is [ImageFormat](https://developer.android.com/reference/android/graphics/ImageFormat.html), although it's not very clear from the very first sight how it's all connected. Range of supported pixel formats is very spartan, though.

* Python has even more options...
  * [PIL](http://www.pythonware.com/products/pil/) provides Image class, which has `Image.fromstring` method, which allows loading of arbitrary raw data in several pixel formats
  * OpenCV + Numpy allows loading of raw images into arbitrary matrices, according to [this SO question](https://stackoverflow.com/questions/18682830/opencv-python-display-raw-image), this is done using `np.fromfile` + `reshape` of resulting array into a matrix.

## Trivial fallback implementation

In case of language / graphic library being unsupported, yet, at the very least, this syntax should provide a better, more readable equivalent of parsing a byte array of required size, i.e.

```yaml
- id: bitmap
  type: bitmap
  width: w
  height: h
  pixels: bgr565
```

instead of

```yaml
- id: bitmap
  size: w * h * 2 # 2 bytes per pixel, as bgr565 = 5 + 6 + 5 = 16 bits
```

Implementing parsing + new internal KS data type + fallback solution shouldn't be that hard. The only hard way is to make a dictionary of pixel format encodings, but that's more or less already done for us in many libraries.