A minimal implementation of f.n.d.Deployement.discover_node_configuration

Here's a very basic implementation of f.n.d.Deployement.discover_node_configuration which returns a list of ``Application``\ s which only have a name.

Other Application attributes (image, volume, internal_links, external_links) will be implemented separately when we have reliable way to retrieve those from the system.

I've:
 * Added `links`, `ports` and `container_image` to the `Unit` record type, so that it can be used...
 * In `FakeGearClient.add` which now stores its internal state as a dictionary of `Unit` instances.
 * although `FakeGearClient.list` still only returns partially populated `Unit`\ s because the real `GearClient` doesn't yet have a way to populate those other attributes
 * So the `ports`, `links` and `container_image` attributes of `Unit` have default values for the time being.
 * I've also added the `Application` record type which for now also has an optional `image` attribute, since the real GearClient can't yet supply enough information.
 * `Deployement.discover_node_configuration` returns a list of these `Application`\ s initialised with a name only.

Fixes #205 
The "zero, one, infinity" rule seems exactly like an argument in support of having this test (along with the tests for the zero and many cases).

It's easy for `test_discover_one` to pass but `test_discover_multiple` to fail.  Just imagine an implementation like:

```
stuff = get_list_of_stuff()
result = mangle(stuff[0])
return [result]
```

There are other mistakes that might be made.  For example, a loop variable being misused:

```
results = []
stuff = get_list_of_stuff()
for item in stuff:
    if condition(item):
        thing = blah
    results.append(mangle(item, thing))
```

This is a simpler case leading up to support for multiple results.  Testing it first can be a good lead up to getting the correct many-results case behavior.