Links v2: Remove graphdb & link aliases

This depends on #7899 getting merged and should be merged and reviewed independently as they are very different changes that depend on each other.

The status quo:

* links use a sqlite database, typically `/var/lib/docker/linkgraph.db`, to hold a graph of container -> name mappings.
* the sqlite databases encourages nested naming (which is how links is currently implemented) with aliases, such as `/cont1/cont2/alias` and this nesting has no upper bound.

The problem:

Let's create two circular referenced links, a feature we want to support in links v2 (the code currently does not support this, and this patch provides no change to that):

* `docker run --name one --link two:alias`: `/one/two/alias`
* `docker run --name two --link one:alias2`: `/two/one/alias2`

The graph now successfully resolves:

* `/one/two/one/alias2`
* `/two/one/two/alias`
* `/two/one/two/one`

... and so on.

The structure of the link graph -- the external representation -- is the problem; it was not designed to handle circular references. I've resolved this by **removing aliases entirely**, and storing maps of the children and their IDs on the container itself. As a result, the graph db is no longer necessary.

Code notes:

1. Lots of tests were changed, all with the intent of testing the new features. They should be reviewed carefully.
1. This removes a lot of what was done in #7899. These things are no longer required, but the separation of these two patches allows us a clean revert path if for some reason this change gets axed. The jobs patches are independent and a fully functional refactor of existing links, while this patch builds on that and changes the functionality itself.
1. parent lookup, as well as a few other parent-like operations need to iterate through all containers. This is done right now with a very straight forward linear time loop. Adding an index is outside of the scope of this change but I do plan to add it before this feature goes live.
1. `docker run --link` may not parse properly if it is the last argument before the image name. I'm not sure what the resolution here is, I don't think there is one. I've removed the offending test but am open to suggestions.
1. After starting the daemon for the first time after this change, your `linkgraph.db` will be populated into the container metadata based on the graph and then the db will be removed. I'm certain this is the safest approach but not sure it's in the best interests of the project. Looking for feedback here.

`Links` is used in various spots for the old links system, which we still have to support in the API. It lives on the `hostConfig` for example. I didn't feel it was a good idea to confuse the two terms so I named this linkmap instead.