sl0ppty: one shader entry, one parser

`parse_shader_entry` is the whole of "what does `dim amount=90
where="chrome" channel="fg"` mean", lifted out of the loop that reads a
`shaders { }` block. The block parser calls it and files complaints; a new
`config_parse_chain` calls it for a chain that came as text rather than as
a file, and hands the compiled expressions back to whoever asked.

Nothing behaves differently. It is a refactor for the next commit, which
lets a program in a pane set that pane's chrome chain: the reason to do it
this way is that a chain typed at a running pane and a chain in a config
file must mean the same thing, or prototyping teaches you something that
then doesn't work when you paste it.

Two details the split had to settle. Expression ownership is now the
caller's -- the config keeps owning the programs a file produced, freed on
reload, and a chain parsed for someone else comes back with its programs
listed so that someone can free them on their own schedule. And a bad
colour no longer drops the pass: it complains and runs at the default,
because a shader at the wrong colour is visible and can be corrected,
while a shader that isn't there looks like a shader that didn't work.

One chain is one rect. The caller says which, and that is the *default* an
entry's `where=` starts from, so a line lifted out of a config still means
what it meant there -- while a line naming the other rect is refused
rather than quietly moved to the one you asked about.

0 files changed, 0 insertions, 0 deletions