Allow volumes_from, network using containers (pre-existing or in fig project), and links to be treated as dependencies.  Also, allow dependencies to be specified explicitly.

Currently services are started in the order defined by links between services.  We also need services that will share volumes to be started in the right order.  And the net: container:foo statement should be recognized as a project service to be started in the right order and with the proper container name being passed to the using services.  Finally, dependencies need to be explicitly called out even if the services don't use links, volumes_from, net, etc. from each other so that if ordering of service start up is needed it happens correctly.

For example, with this fig.yml file, we will be guaranteed that the data container starts before the db container which starts before the app container which starts before the web container.  And the network container will start before all the rest and it's container id will be properly passed to the using containers.  This allows the "kubernetes pod" type system to be set up easily which was hard to set up with fig before.

```yaml
web:
  image: webimage
  net: "container:network"
  depends_on:
    - app
app:
  image: appimage
  net: "container:network"
  depends_on:
    - db
db:
  image: dbimage
  volumes_from:
    - data
  ports:
    - 1529:1529
data:
  image: dataimage
  volumes: /foo
```
The internals of dependency management have been modified quite a bit with most changes to service.py and project.py.  The unit and integration tests have been modified to check that it all works.
Regarding the deep copy, the goal is to not allow a service to be created with volumes, links, etc. passed to it because it won't understand the dependencies - only the project knows that.  It would be easy to allow those keys to be passed to the Service instantiation where they would be ignored and let the project do it's thing later.  That would avoid needing the temp dictionary.  But I was trying to be more prescriptive with the service and not allow those dependency related keys to be passed to it which necessitated removing them from the dictionary.  I'm not a python expert so any guidance would be appreciated and I can update my fork.

Regarding separating the net container and depends_on functionality - it can be done but they both rely on the dependency management refactoring.  So removing one or the other doesn't buy that much.  It's all one big related change.

The build dependency issues which you referred to are fixed by adding the "depends_on" key.  If two builds have to happen in order the "depends_on" key will get the job done with a fig up.  Fig build won't recognize the dependencies at this point although that could be added using the dependency ordering.