remove wal_level archive

So we've had several rounds of discussions about simplifying replication
configuration in general and the wal_level setting in particular. [0][1]
Let's get something going. While we have not reached a complete
consensus yet, a few things have become clear:

- We would like to have fewer or easier to change settings.

- It looks like some folks would prefer a switchover to a completely new
and better system, but my experience in these kinds of matters is that
it's better to take smaller steps or we won't get anything changed.

- The distinction between wal_level settings "archive" and "hot_standby"
is in the way of automation or better intelligence, because the primary
cannot tell what the receiver intends to do with the WAL.

So here is a patch to get rid of the distinction.

Bike-shedding: In this patch, I removed "archive" and kept
"hot_standby", because that's what the previous discussions suggested.
Historically and semantically, it would be more correct the other way
around. On the other hand, keeping "hot_standby" would probably require
fewer configuration files to be changed. Or we could keep both, but
that would be confusing (for users and in the code).

I kept the distinction between XLogIsNeeded() and
XLogStandbyInfoActive(), because it is kind of nice for documentation
(although the names are terrible).

The changed comment in xlog_redo() could probably use some review or a
bit more detailed reasoning.

There were a couple of places that I felt were overly coupled with the
wal_level settings. The XLogArchiving*() macros shouldn't really care
what wal_level is, because that is checked elsewhere. I replaced that
with assertions. The check in CheckSlotRequirements() seems
unnecessary. Why can I not add and remove slots while wal_level is minimal?

The documentation and error messages could also use more overhaul. Some
parts say things like "archive or higher", implying that the user knows
about the ordering, other parts list all the allowed options, possibly
implying that they are mutually exclusive variants.

Maybe some of these things could be split out into separate patches.

[0]:
http://www.postgresql.org/message-id/20150203124317.GA24767@awork2.anarazel.de
[1]: http://www.postgresql.org/message-id/55D31E0D.8060801@gmx.net