Make ered an application with its own supervision tree

[zuiderkwast]

This PR contains some separate commits. It might be better to review them one by one.

• Merge ered and ered_cluster processes

  The command handling code is moved from ered to ered_cluster. The ered
  module becomes just an API module without a process of its own. This
  eliminates some duplicated structures and copying between processes.

  Change ered_client_sup into to simple_one_for_one supervisor.

• App and supervision tree

  Ered becomes an application with its own supervision tree.

  In the API, connect_cluster/2 replaces start_link/2 and close/1 replaces
  stop/1. The processes are added to ered's own supervision tree. An ered
  instance monitors the caller and closes down if the owner dies, much like
  the controlling process concept in gen_tcp and ssl.

• Add info message 'cluster_stopped' sent in ered_cluster:terminate/1

  The process traps exits so terminate/1 will run even if the process
  crashes.

• Unify info messages from ered_client and ered_cluster

  Make the messages sent by a standalone ered_client match those sent
  by a cluster client for each client, i.e. a map with the keys
  msg_type, reason, client_id, addr and the optional fields
  cluster_id and master.

[ioolkos]

I have a quick question on line:

ered/src/ered_client.erl

Line 236 in 4374c5e

({auth, Auth = {_, _}}, S) -> S#opts{auth = Auth};

is it by design that sth like ({auth, Auth = none}, S) -> S#opts{auth = Auth}; is missing here?
At least in connect {auth, none} seems to be allowed.

I built a little plugin using ered as an application as in this PR. Works great so far! :)

[bjosv]

It's a big change but I haven't found anything more to comment on after a couple of walkthroughs.
It's a good sign that the tests are more or less unchanged.