Clippy is returning some warnings.  Let's fix or explicitly ignore
them.  In particular:

- In `components/imageproc/src/lib.rs`, we implement `Hash` explicitly
  but derive `PartialEq`.  We need to maintain the property that two
  keys being equal implies the hashes of those two keys are equal.
  Our `Hash` implementations preserve this, so we'll explicitly ignore
  the warnings.

- In `components/site/src/lib.rs`, we were calling `.into()` on some
  values that are already of the correct type.

- In `components/site/src/lib.rs`, we were using `.map(|x| *x)` in
  iterator chains to remove a level of indirection; we can instead say
  `.copied()` (introduced in Rust v1.36) or `.cloned()`.  Using
  `.copied` here is better from a type-checking point of view, but
  we'll use `.cloned` for now as Rust v1.36 was only recently
  released.

- In `components/templates/src/filters.rs` and
  `components/utils/src/site.rs`, we were taking `HashMap`s as
  function arguments but not generically accepting alternate `Hasher`
  implementations.

- In `src/cmd/check.rs`, we use `env::current_dir()` as a default
  value, but our use of `unwrap_or` meant that we would always
  retrieve the current directory even when not needed.

- In `components/errors/src/lib.rs`, we can use `if let` rather than
  `match`.

- In `components/library/src/content/page.rs`, we can collapse a
  nested conditional into `else if let ...`.

- In `components/library/src/sorting.rs`, a function takes `&&Page`
  arguments.  Clippy warns about this for efficiency reasons, but
  we're doing it here to match a particular sorting API, so we'll
  explicitly ignore the warning.

* Add hard_link_static config option.

* Copy or hardlink file depending on an argument.

Modify the call sites for `copy_file` to account for the extra argument.

* Plug the config setting through to copy_file.

Don't apply the config option to theme's static directory.

* Update documentation.

* Backticks make no sense in this comment.

* Addressing PR comments.

* Be consistent with argument naming.

* Add --open flag to serve command, to open URL in default browser

* Mention serve --open flag in CLI documentation

Closes #712

* actix_web::fs is now found in the actix-files crate.

* NotFoundHandler is now implemented using ErrorHandlers and the
path to 404.html is provided to the not_found() function using
actix_web::App::data. This setup allows for additional StatusCodes
to be handled in the future, if desired.

* Cleanly serving index.html files for requests to directories now
appears to be possible simply by using index_file("index.html") in
the static files service, so handle_directory() is removed.

* Add check subcommand

* Add some brief documentation for the check subcommand

* Start working on parallel link checks

* Check all external links in Site

* Return *all* dead links in site

To also process the ones found in templates

Closes #669

This reverts commit 1815155c1d.

Closes #667

Closes #607

trim_{start, end} is introduced in rust 1.30.0 and
trim_{left, right} is deprecated since 1.33.0.

Closes #576

Closes #554

Closes #385

Fix #445

* Replace hard-coded directory slash in serve output

- unless forced, only use colors in tty
- support CLICOLOR and NO_COLOR vars
- switch to termcolor crate to handle output coloring

Closes #418

Otherwise Path won't know what to do.

Delay turning paths into string. Instead, use methods on Path/PathBuf
to manipulate paths. This way the Rust Path implementation gets to deal with
all werid cross-platform issues.

This should fix #359

Since we are using a builtin template, we can be assured to have the
target file in place. Middleware renamed since it is bound directly to
the concept of handling 404s.

This is a proposed successor to #296 (rewritten for actix-web, rather
than iron).

Users can now place custom error pages in static/error/<error_code>.html
e.g. static/error/404.html

If no custom page is found, a default plaintext describing the error is served.

I filed actix/actix-web#261 as per the maintaner's request while
working on #310.

Having looked at the issue this morning, it appeared there was an
implementation to convert `io::Result` into a `Responder`, which kicked
in when I tried to access the `respond_to()` method without getting the
inner type from that first result before hand.