* added framebuffer support:
   * gist: the framebuffer is a specially handled collection of images that are automatically read from and written to by the pipeline (+access across rasterization program calls)
   * completely user specifiable (any number, any type and any mixture of types for all "color" images/attachments)
   * depth buffer must be of type FLOAT_32/R or not exist at all (not sure if I'm going to extend this in the future, FLOAT_32 seems to be the most reasonable choice)
   * preliminary stencil buffer support (can be specified, but is not used yet; must be of type UINT_*/R)
   * framebuffer images inside a user program are specified via "oclraster_framebuffer", same syntax as "oclraster_images" with the addition of "depth_image" and "stencil_image", and the exclusion of "image1d" and "image3d"
   * note: the framebuffer interface on the host side is only temporary; in the future this will not create images itself, but images must be attached/bound to it
   * note: there is no support for/specific handling of 32-bit and 64-bit integer and 64-bit float formats yet (all other types, UINT_8/UINT_16/INT_8/INT_16/FLOAT_16, are converted to normalized 32-bit floats)
   * note: all framebuffer images must be backed by an opencl buffer, not an opencl image (same rule that applies to all read_write images: OpenCL doesn't allow native read_write images)
 * added image read functions with unsigned integer coordinates (nearest filtering only, as per OpenCL spec and obvious reasons)
 * pipeline now has a default framebuffer (UINT_8/RGBA color + FLOAT_32/R depth) which is used for final window blitting/swapping and when no user framebuffer is bound
 * modified oclr_simple sample according to the changes above
 * bumped version