Bumps [bestzip](https://github.com/nfriedly/node-bestzip) from 1.1.4 to 2.1.7.
- [Release notes](https://github.com/nfriedly/node-bestzip/releases)
- [Commits](nfriedly/node-bestzip@v1.1.4...v2.1.7)

Signed-off-by: dependabot[bot] <support@github.com>

This helps fix the issue with the zero padding (2 -> 02) occuring
while typing, and instead allow it to happen after an input
is considered settled

The settings page gets the initial settings and passes along with
handlers for on submission and on close.

Add tests and fix luxon `diffNow` usage with has-date-past

By loading a photo and then getting the settings on subscription
creates a double-load and a flickr.

* Ensure image is fully loaded before showing wallpaper
* Use vw and vh units instead of 100% for width and height
* Use object-fit with img tag instead of background-image with div

* change prettierrc to use spaces instead of tabs

…directory

Using hashes to track routes in urls is better for chrome
extensions. This is because the default of providing a route at
/settings for example doesn't map in extension land to a .html

There is probably a way of intercepting route changes in
extensions for urls and redirecting them but this would require
escalated privledges and be harder to test.

The other method of generating a prerendered .html file for every
route almost worked except svelte's routing doesn't recognize
a route at its .html location once it's loaded. It wants to deal
with goto("/settings"), it doesn't recognize
goto("/settings.html").

The hacky workaround I have here works pretty well. Every route
change that happens it goes and replaces the current route with
a corresponding hash representation.

If someone reloads the page the hash representation needs to be
mapped back to its corresponding route and then navigated to
that route by svelte's `goto`. Upon entering that route it will
again have its url replaced with its hash match.

This method also helps encapsulate the swapping of the routes
to be friendly for local dev server or extension. In the case of
the extension the hash is at "index.html#route" and when being
served by the local dev server it is replaced with "/#route".

While this is hacky it is consistent and allows for everything
to be handled entirely "in app". If this app were to increase the
number of routes it had to manage then this hash mapping would
become less sustainable and maybe more research into how other
svelte apps handle this challenge would be warranted.

If there was already a chrome tab opened then going to the options
would not open a new tab at #settings nor would it update the
existing opened tab to #settings, resulting in the options button
linked from the browser's extension page essentially noop'ing.

This dedicated settings.html does a local js redirect to
index.html#settings and that way every new tab opened by the
browser's extension option page will end up at index.html#settings

This means that the bg will be rendered before any js and css is
loaded and parsed, hopefully reducing the amount of "white" flash

This commit adds a route that is as an ugly hack for when
"index.html" loads and it tries to load the corresponding route.
Without this "index.html" route the router can't find a matching
route, throws an error, but still ends up at the default route
(so the user doesn't notice the issue) but it leaves an ugly
error in the console.

By having an "index.html" route which is a shortcoming of being
able to serve from static files like within extensions, this
route kicks things off by navigating to the root route "/".