Updates swayimg (new Lua configuration files are required) and adds support for new image formats.

Testing the changes

• I tested the changes in this PR: YES

I have confirmed all files required by CONFIG.md are present (see #59385):

• /etc/xdg/swayimg/init.lua
• /usr/share/swayimg/example.lua
• /usr/share/swayimg/swayimg.lua

Local build testing

• I built this PR locally for my native architecture, (x86_64-musl)
• I built this PR locally for these architectures (if supported. mark crossbuilds):
  • armv6l-musl

I tried vconf as well (to avoid the conf_files declaration) but that doesn't create the parent directories. vinstall seems the best option to me (with my limited xbps knowledge).

That still leaves us w/ the other two example.lua files (see my other comment) - again, it's for the person doing the merging to decide whether they want to keep any of those files, or if they prefer to not install anything into etc and let the user figure it out by referring to the *.md files (personally, I'd just keep /etc/xdg/swayimg/init.lua and be done w/ it)

I'm in favor of keeping both copies of example.lua. Yes, it's redundant, but it's in accordance with swayimg's CONFIG.md instructions. In case a user follows them, there won't be any missing files.

I believe more problems will arise from a poor transition between the old and new configuration files, as support for old configs was completely removed without prior warning.

My point is, that w/ the proposed changes to the template the following identical (content-related) files will be installed

/usr/share/swayimg/example.lua # by upstream
/usr/share/examples/swayimg/example.lua # by 'vsconf'
/etc/xdg/swayimg/init.lua # by 'vinstall'

where the second is arguably the most redundant (for not being mentioned in the docs)

Regarding the transition to the new lua-based configuration, consider adding an INSTALL.msg (please wait for a member to step in)

Yeah, you're right, I misread /usr/share/swayimg/example.lua as /usr/share/examples/swayimg/example.lua, my bad. I can fix it tomorrow morning (UTC+1). Regarding INSTALL.msg, yes, let's wait for a repo maintainer to give their opinion.