GPU kernel launches must use the same amount of shared memory per block,
and this has to be computed ahead of time on the host. The expression
that gives the size of the allocations compute_at blocks are inside the
kernel though, and are a function of bounds inference. We therefore have
to take the max of these sizes over all blocks. This is extremely prone
to interval arithmetic being overconservative, because these are extents
computed from a max minus a min, and the max and min are both frequently
correlated with the block variable. This causes a lot of otherwise fine
schedules to fail at runtime with CUDA_ERROR_INVALID_VALUE.

This PR detects cases where interval arithmetic is going to be
overconservative using is_monotonic, and hoists the computation of
shared memory size to an explicit loop over blocks on the CPU, taking
the max shared allocation size exhaustively. This implies some work on
the CPU, but

1) A loop over blocks is typically at least 32x fewer iterations than
the loop over pixels
2) This work can overlap with the previous kernel launch on the GPU
still running
3) The alternative is crashing

This feature has proved to make GPU schedules much more robust in the
gpu autoscheduler branch, so I think we should promote it to master.

It's a bit wild though, because this is the first instance I can think
of where we inject a new unscheduled loop for some bounds inference
purpose.