- Adds a new interface, Apper, that enables loading and persisting
  instance-level data in new ways
- Converts some initialization funcs to methods
- Exports funcs and methods needed for intialization
- In general, moves a ton of stuff around

Overall, this should maintain all existing functionality, but with the
ability to now better manage a WF instance.

Ref T613

This ensures the writefreely pkg can be used in other applications that
need to load mysql themselves -- this can be done by building with the
tag: wflib

Ref T613

Ref T613

This adds a new `landing` value in the [app] section of config.ini.
If non-empty, unauthenticated users on multi-user instances will be
redirected to the path given there.

This closes T574

This adds a new `landing` value in the [app] section of config.ini.
If non-empty, unauthenticated users on multi-user instances will be
redirected to the path given there.

This closes T574

Now the func takes a username and password instead of a single string.

This exposes setup and admin functions in the writefreely package, and
uses them in the main application, initialized by the flag parsing that
now happens there.

This is the first step towards making `writefreely` usable as a
standalone package.

This makes it so we can keep all schema changes in the `migrations`
module, instead of adding them there *and* in the schema files. It
fixes #92 and should prevent these kinds of issues in the future.

Now admins can choose a title for their About and Privacy pages; now
editable through the instance page editor.

This adds `title` and `content_type` fields to the `appcontent` table,
requiring a migration by running `writefreely --migrate`

The content_type field specifies that items we're currently storing in
this table are all "page"s; queries for fetching these have been updated
to filter for this type. In the future, this field will be used to
indicate when an item is a stylesheet (ref T563) or other supported
type.

Ref T566

This adds a "Pages" section to the admin part of the site, and enables
admins to edit the pre-defined About and Privacy pages there, instead of
on the dashboard itself.

It also restructures how these pages get sent around in the backend and
lays the groundwork for dynamically adding static pages. The backend
changes were made with more customization in mind, such as an
instance-wide custom stylesheet (T563).

Ref T566

Previously, our hashtag parser would indiscriminately replace
hashtag-like text with hashtag HTML -- including in places it shouldn't
have, like inside code blocks. Along with the v1.7.0 changes to
writeas/saturday, this fixes that and closes #6.

As a bonus, strings of #spaceless#hashtags#in#a#row are now rendered
correctly.

...instead of using os.Exit(). This makes it more apparent what's going
on, less error-prone, and more consistent with other command logic paths.

...instead of doing os.Exit(). This allows the func to be used in many
places (as it is) and handle success results in different ways.

Previously, this caused the single-user configuration process to exit
prematurely. This fixes that and closes #71.

This includes the appmigrations table in the schema files, and inserts
the current database version when running writefreely --init-db

This makes --gen-keys respect the keys_parent_dir config value

This adds new configuration values that specify the parent directory of
application resources:

- templates_parent_dir
- static_parent_dir
- pages_parent_dir
- keys_parent_dir

For any values not specified, the application will default to the
current directory.

This closes T560

This adds new configuration values that specify the parent directory of
application resources:

- templates_parent_dir
- static_parent_dir
- pages_parent_dir
- keys_parent_dir

For any values not specified, the application will default to the
current directory.

This closes T560

This runs database migrations and obviates the need for manually running
changes.

Ref T509

This fixes the --config step so that when setting up a single-user
instance for the first time (and creating the admin user as part of the
process), the database is automatically initialized before creating that
user.

This removes the need for the --init-db command after --config when
setting up single-user instances.

It fixes #59: "no such table: users" error during the --config step on
single-user instances that haven't previously run --init-db.

SQLite doesn't have an `RLIKE` function, so the query for hashtagged
posts was failing before. This adds a `regexp` function to SQLite and
correctly retrieves all posts on a blog with the requested hashtag.

This closes #55

This adds a new `sqlite` build tag that you should include only if you
want SQLite3 support built in. Both `make run` and `make release` create
builds with SQLite included.

This includes schema.sql and sqlite.sql in the release binary, so they
no longer need to be included in the release archives. This reduces the
number of files extracted, but otherwise leaves all functionality as it
was -- especially the --init-db flag.

Ref T536

This supports creating a regular user via the command-line.

This runs usernames through the same checks as the web interface,
ensuring no invalid user is created, such as user_name or userName.

This closes #49

This adds a "Reader" section of the site for admins who want to enable
it for their instance. That means visitors can go to /read and see who
has publicly shared their writing. They can also follow all public posts
via RSS by going to /read/feed/. Writers on an instance with this
`local_timeline` setting enabled can publish to the timeline by going
into their blog settings and choosing the "Public" visibility setting.

The `local_timeline` feature is disabled by default, as is the Public
setting on writer blogs. Enabling it adds a "Reader" navigation item and
enables the reader endpoints. This feature will also consume more
memory, as public posts are cached in memory for 10 minutes.

These changes include code ported over from Read.Write.as, and thus
include some experimental features like filtering public posts by tags
and authors. These features aren't well-tested or complete.

Closes T554

This allows users to load a different configuration file instead of the
default config.ini. It works in combination with other configuration
actions, like --config and --create-config.

Ref T529

This enables automated user creation by running:

  writefreely --create-admin username:password

It will fail if an admin (first user) already exists, which makes this
suitable for use on both for single- and multi-user instances.

Closes T544

A quick test with ApacheBench revealed that SQLite really can't handle
multiple concurrent requests with the default settings, due to a locked
database. This fixes that by following the suggestions here:
https://github.com/mattn/go-sqlite3#faq

Testing with ab -n 100 -c 5 http://localhost:8080/blog/post shows that
this fixes the issue. But we could improve performance by reducing
writes, like what's mentioned in T545.

Part of T529