TL;DR: This PR adds integration tests, which fail. Fixing the tests is a much
larger change made in a separate PR.

As I was working on some Fx modules that use dig, I noticed some behavior that
surprised me. In exploring dig's code, I realized that many of my assumptions
about how the library should behave aren't covered by dig's testing suite.

In this PR, I've added a bunch of end-to-end tests in the top-level dig package.
Those tests *only* use the public `Provide` and `Invoke` APIs to verify that the
behaviors Fx needs work correctly. I haven't altered any of dig's production
code.

Unfortunately, these tests exposed a number of bugs:

```
$ go test . | grep FAIL

    # Container.Provide(nil) panics.
--- FAIL: TestCantProvideUntypedNil (0.00s)

    # The container allows us to provide errors, but via some code paths.
--- FAIL: TestCantProvideErrors (0.00s)

    # All types in the graph must have their deps satisfied, even if nobody's
    # using them.
--- FAIL: TestIncompleteGraphIsOkay (0.00s)

    # Container doesn't detect cycles.
--- FAIL: TestProvideCycleFails (0.00s)

--- FAIL: TestEndToEndSuccess (0.00s)
    # We can't provide slices or maps from standard constructor functions, but
    # we can provide instances. Elaborate constructors like `func() []Foo, int,
    # error` also work correctly.
    --- FAIL: TestEndToEndSuccess/slice_constructor (0.00s)
    --- FAIL: TestEndToEndSuccess/map_constructor (0.00s)

    # We can't provide both []Foo and Foo, since dig considers them the same
    # type.
    --- FAIL: TestEndToEndSuccess/collections_and_instances_of_same_type (0.00s)
```

This is concerning to me, since dig has 89% code coverage. Fixing these bugs and
structuring the code so that we can confidently refactor without breaking
user-facing behavior was a larger change, so I've broken it out into a separate
PR.