Yes, it's possible to implement that.
A simple way would be to use a shell script that would call snapper repeatedly, once for each config. A for loop would be enough to do that, it seems.
You can even do it inline in the systemd unit file:
ExecStart=/bin/sh -e -c '. /etc/conf.d/snapper; for conf in $$SNAPPER_CONFIGS; do /usr/bin/snapper --config "$$conf" --cleanup-algorithm number --description "boot"; done'
Note that you need to escape the $s, so that systemd doesn't try to interpret those as systemd variables and instead lets the shell interpret them. (In my opinion, using an external shell script that you call in ExecStart= is a cleaner approach, then you don't need to deal with escaping and don't need to cram everything into a single line either.)
Another option would be to modify snapper itself so it could handle that natively. Say, make it read that config file and handle those configs whenever it's called without any --config arguments. That would be an even cleaner approach.
Whether it's advisable or not... I guess it depends. If you're getting this snapper-boot.sevice unit from a package from your distribution, then you might have trouble whenever there's a package upgrade that would touch that file. So, in a way, it depends on your particular situation.
If this unit file is indeed shipped with a package from your Linux distribution, you might want to consider opening a bug report to them, asking them to avoid hardcoding config names in the unit file.
If it's not owned by your distribution, then consider storing it in /etc/systemd/system instead, since the /usr/lib is typically reserved for files shipped and managed by the Linux distribution.
