Light removal is still somewhat broken and
sometimes cause lingering light data

+ Ensure widening cast safety

- Enqueue only occlusion change
- Compare based on pure light
- Skip empty queue (don't upload)

Except for light sources which propagate in every direction.
Bright nodes found while looping through light removal (decrease)
queue are treated as light sources.

- Fix light source restoration; was blocked by occlusion check

Don't use queue since we already have per region queue

Add froglight colors
Rename light data texture to "canvas:alpha/light_data"
Cleanup cruft

- API registry only holds pure RGB
- Always cache all light
- Restructure and separate "API" from internal code

- Remove decrease self occlusion check completely,
  Occluding blocks should be able to propagate decrease
  outwards after all.
- Add more filtering for increase queuing
- Some simplifications

This is done by fully parsing pipeline description, which impacts
resource reload time.

This feature is more than just providing light volume, since we also
do propagation and manage the custom light color registry.

And ultimately the goal is to add colored lights. Voxel tracing, LPV,
and other light volume related aspects would count as separate or
spin-off projects.

- Built-in selective neighbor filtering
- Move decrease and increase operations to LightOp
- Do multiple loop for increase too

It's a tad more complex

This also includes "fix" for a bug that was discovered
after sampling was improved. The bug remains, this only
reduces the frequency (pretty much "edge case" for now).

Additionally: respect useOcclusionData for sparse allocation

- Light texture consists of: pointer-meta header, pointer storage, and
data storage
- Generates new texture when the storage (data or pointer) is doubled
- Sampler bindings are now `int` suppliers to account for changing light
texture ID
- Pipeline declares occlusion data usage as it impacts number of
allocation

Possibly temporary:
- Pipeline declares active radius for light execution. This won't be
necessary if light execution is actually scalable
- Reclaimable addresses are stored in an array-backed stack. This
might be slow
- Pointer-meta header might be moved to uniforms for simplicity

NOT (yet) implemented:
- Built-in light sampler for material programs
- Prevent pipeline stalling by writing to a swap buffer
- Proper registry for built-in textures available to use by program
passes

Should have been done earlier:
- Remove notions of extent-origin and redrawing when origin was moved
- Redraw every allocated regions on texture remake instead of the above

Experimentally:
- Iterate through queue using native malloc "array"
(slightly faster than regular array)

Additionally:
- Checkstyle fixes

Colored lights sparse allocation

- Minor style change

Some light levels are adjusted to account for perceived luminance.
Note that this is inaccurate.

… issue

Note: simple deque is faster than Set, likely takes more memory

- Revert LightDataManager.reload() change from 2 days ago

- Shorten profiler output

…entity

- Rename VirtualLightManager to LightLevel
- Make item light encoding consistent in LightRegistry and everywhere
- Reformat

- Entity JSON light is a simple light without predicate
- CachedBlockLight -> FloodFillBlockLight, make all values consistent
- `blaze` and `glow_squid` light in canvas/default resource pack
- EntityLightProvider API (unused for now)

- More robust LightLevel and EntityLightTracker reload
- More robust CanvasState requireReload

Our flood fill-based model doesn't support HDR, so it's better to preserve
the color hue instead of clipping to white on high intensity.