3bgl-shader updates: compute shaders, etc

Working on cleaning up/documenting the changes made to 3bgl-shaders due to recent experiments with compute shaders. (some of these were already committed but not documented)

New features/changes:

Don't :use :cl anymore

Instead of worrying about which symbols to shadow when :useing both :cl and :3bgl-glsl, (:use :3bgl-glsl/cl) handles it automatically.

:3bgl-glsl/cl exports everything exported from :3bgl-glsl and :cl, preferring the former where there are conflicts.

The name isn't final yet though, might switch to using the shorter name for the combined package.

DEFMACRO works from shader code

3bgl-glsl:defmacro (exported by :3bgl-glsl/cl) allows defining macros for shader code, and should work as expected. Macro functions are evaluated by host, so can use arbitrary CL code at compile time.

macrolet also works, also allowing arbitrary CL code for computing the expansion.

More control over uniforms

The uniform macro accepts new arguments :layout and :qualifiers, for things like restrict and specifying image formats (:rg32f, etc)

shared memory

The new shared macro allows defining glsl shared variables for use in compute shaders, for example (shared temp (:float 512)) declares an array of 256 floats to be shared within each workgroup of a compute shader invocation.

Local-size-* declarations for compute shaders

Compute shaders need the workgroup size specified in the kernel, which can be done with the layout declaration:

(defun foo()
  (declare (layout (:in nil :local-size-x 16 :local-size-y 16 :local-size-z 1)))
  ...)

Partial support for arrays

Arrays are supported for shared variables, and partially for local variables.

Type inference doesn't detect arrays yet so type must be declared explicitly, and array variables can't be initialized yet.

Both currently use the syntax (<base-type> <count>) rather than CL vector or array type specifiers.

(let (a)
  (declare ((:float 32) a))
  (setf (aref a 12) 34)
  (aref a 12))

MOD works on float and integer types

Previously mod had conflicting definitions, so only worked on some types, now it expands to % or mod() depending on the derived argument type.