Rather than requiring a traditional crontab install, the app now
leverages quantum-core (link below) to schedule the instance update/sync
task every 5 minutes. Some updates as a result:

  - The new job is scheduled at runtime in server.ex.
  - The update.exs script was refactored to be compiled along with the
    rest of the app as instances.ex.
  - Scheduler and Server modules were added for creating and executing
    the new update task
  - All shell scripts were removed, as they are no longer needed

https://github.com/quantum-elixir/quantum-core

This adds a couple of new scripts: install-crontab.sh and update.sh. The
install-crontab script does exactly that -- it installs a new crontab
that runs the update script every 5 minutes. An update script was added
to simplify the crontab a bit and to ensure the Elixir update script is
executed from the correct directory.

Introduces a new db key "<service>-previous" to track which instance was
last selected for a particular service. This allows for filtering the
list of available instances to exclude the instance that was last
picked, to ensure a (slightly) more even distribution of traffic.
There's still the possiblity of the following scenario, however:

:service instances > 2

/:service request #1 -> instance #1
/:service request #2 -> instance #2
/:service request #3 -> instance #1
/:service request #4 -> instance #2

where there are many ignored instances for a particular service. One
possible solution would be to implement the "<service>-previous" value
to be a list, rather than a single value, and push to that list until
only one element is left in the original "instance" array after
filtering, and then delete the "<service>-previous" key.

Service struct now defined in lib/service.ex

This makes a bit more sense now that its a shared resource, rather than
just defining it only in the update.exs script.

Now allows setting FARSIDE_TEST to skip individually fetching each
instance, and instead just adds all of them to redis instantly. This
allows for an easier time in CI builds, for both the sake of speed and
to prevent a scenario where many simultaneous builds have a noticeable
impact on actual instances.

This introduces a number of new changes:
- Services are now inserted into redis with a prefix prepended to the
key name. This allows for easier filtering to get only live instances.
- The home page now uses an eex template for displaying all live
instances for every service, determined by the last update
- A "last_updated" field was added
- farside.ex was added to contain all functionality related to querying
for instances (WIP)
- Other improvements

The name of the project is being refactored from Privacy Revolver to
Farside. The reasoning behind this is:
1. A shorter name is easier to remember
2. It can stand for "FOSS alternative redirecting service" (which I know
doesn't encapsulate all letters from "farside", but it's close enough).

This commit also includes improvements to the update script for
determining how far along the script is.

Not sure if this is the Elixir-y way to do this, but seems more logical
than hardcoding values such as redis connection.

Also went through and improved how string formatting was performed
throughout the app. Rather than "combining" <> "strings" this way, I'm
now just doing "#${variable}#{formatting}", which looks a lot cleaner.

The update script now writes the available instances to a
.update-results* file (where previous runs have "-prev" appended to the
file name). This helps to see how instance availability changes between
runs of the script when debugging overall functionality of the app.

Once a list of available URLs has been determined for a particular
service, the list is written as "service -> [list of instances]" to a
local redis connection. These can then be used in the greater routing
logic to pick a random instance from the list, or use a fallback
instance if none are determined to be available.