Wallpaper overhaul

[Zohiu]

I was told that you'd like some more wallpaper options, so I changed your wallpaper system to make it easier to add new ones, then added new ones. I think I explained all my choices pretty well here, so if you think something seems odd, ask me about it because it might just be a mistake / logical error on my side.

Small Changes

• Added small blurry drop shadow to the Username to increase readability with some wallpapers

Functions

• The wallpaper functions are now contained in a single const JSON object, which allows executing them based on a key string direcly from the config -> More elegant than a big switch statement for all possible choices and easier to extend with additional wallpapers.
• The same key from the config is also used to access the config json file.

Multi-wallpaper support

• The config now uses an array for setting wallpapers, allowing users to display multiple of them at once, which makes it a bit more flexible.
• I called the config option "wallpapers" <- (added an "s") which is the default now, but the old "wallpaper" option still gets recognized so that old configs don't break from updating. If one uses both options, the singular "wallpaper" takes priority as it overwrites the new one.
• I renamed the "move-keyframes" to "particledrift-move-keyframes" to differentiate it better from other wallpapers when multiple are active. Otherwise, there would be conflicts.

DOM-interaction

• The wallpaper functions now don't directly interact with the DOM (With the exception of injecting style in the head). They return a new div that contains the wallpaper. That div then gets added to the #wallpapers element by the code at the bottom. Why? - It "forces" the wallpaper functions to follow the rules to hopefully prevent conflicts when showing multiple wallpapers at once - They should not accidentally interact with eachother's elements.
• A sideeffect of this change: Before my changes, the particledrift function added each particle directly to the DOM one-by-one which has some performance overhead (maybe even flicker on some super slow devices?) from all the refreshing. Not that important in this specific case, but I would consider this better practice.

New "content"

"Gradient" wallpaper

Good for use as background in multi-wallpaper mode. Displays a simple linear gradient.

"Brokenglass" wallpaper

Creates completely random colored polygons with a slight blur effect. It might look a bit rough at times.

"Characterdrift" wallpaper

Works just like particledrift, but uses characters. That includes emojis - Anything the site owner wants. No blur on this one.

Security concerns??

Using the values from the config directly to run functions and access files seems like a bad idea because there is no filtering or purification, but at the end of the day only the site owner can edit the configs and they already have the ability to add whatever they want to the code anyway, so I don't think this is an issue.

Readme

I did not change the readme at all, so merging this would require some changes there.

[nandolawson]

Great work, thank you very much! I'll deal with ESLint's complaining later, otherwise I'll leave the code as it is.