Checkout spends a lot of time cloning submodules

* `carthage version`: 0.20.1
* `xcodebuild -version`: 8.2.1(8C1002)
* Are you using `--no-build`? YES
* Are you using `--no-use-binaries`? YES
* Are you using `--use-submodules`? NO
* Are you using `--cache-builds`? NO

**Cartfile**
```
github "ReactiveCocoa/ReactiveCocoa"
```

I'm running `carthage checkout --no-use-binaries`, it is slow.

I insert some log in the `cloneSubmoduleInWorkingDirectory` signal producer:

This is the output:

```

*** Checking out Result at "3.2.1"
*** Checking out ReactiveSwift at "1.1.0"
2017-03-14 13:53:58.433 carthage[57473:1990312] start clone submodule Carthage/Checkouts/Nimble @ 8e2703fabde578a6d28537c73844f84d48e71200
2017-03-14 13:53:58.458 carthage[57473:1990312] start clone submodule Carthage/Checkouts/Quick @ e4fa1e85c0305ba4e0866f25812d3fa398f3a048
2017-03-14 13:53:58.472 carthage[57473:1990312] start clone submodule Carthage/Checkouts/xcconfigs @ 3d9d99634cae6d586e272543d527681283b33eb0
2017-03-14 13:53:58.489 carthage[57473:1990307] start clone submodule Carthage/Checkouts/Result @ 2dd1a0c7bca4cc44082f72020fe8b14491056f88
2017-03-14 13:54:06.657 carthage[57473:1990308] complete clone submodule Carthage/Checkouts/xcconfigs @ 3d9d99634cae6d586e272543d527681283b33eb0
2017-03-14 13:54:23.253 carthage[57473:1990308] complete clone submodule Carthage/Checkouts/Result @ 2dd1a0c7bca4cc44082f72020fe8b14491056f88
2017-03-14 13:56:19.237 carthage[57473:1993541] complete clone submodule Carthage/Checkouts/Nimble @ 8e2703fabde578a6d28537c73844f84d48e71200
2017-03-14 14:00:21.046 carthage[57473:2009707] complete clone submodule Carthage/Checkouts/Quick @ e4fa1e85c0305ba4e0866f25812d3fa398f3a048
*** Checking out ReactiveCocoa at "5.0.1"
2017-03-14 14:00:21.164 carthage[57473:2009731] start clone submodule Carthage/Checkouts/Nimble @ 3720e6b0f6de6d6435f79f8a174fb4bb92df5dc4
2017-03-14 14:00:21.204 carthage[57473:2009755] start clone submodule Carthage/Checkouts/Quick @ e4fa1e85c0305ba4e0866f25812d3fa398f3a048
2017-03-14 14:00:21.276 carthage[57473:2009755] start clone submodule Carthage/Checkouts/xcconfigs @ 3d9d99634cae6d586e272543d527681283b33eb0
2017-03-14 14:00:21.315 carthage[57473:2009749] start clone submodule Carthage/Checkouts/Result @ 2dd1a0c7bca4cc44082f72020fe8b14491056f88
2017-03-14 14:00:21.349 carthage[57473:2009749] start clone submodule Carthage/Checkouts/ReactiveSwift @ c83de32f1adbcef89618cde4222f69a8bcecd7c2
2017-03-14 14:00:35.112 carthage[57473:2010340] complete clone submodule Carthage/Checkouts/xcconfigs @ 3d9d99634cae6d586e272543d527681283b33eb0
2017-03-14 14:00:43.678 carthage[57473:2010338] complete clone submodule Carthage/Checkouts/Result @ 2dd1a0c7bca4cc44082f72020fe8b14491056f88
2017-03-14 14:03:50.218 carthage[57473:2017892] complete clone submodule Carthage/Checkouts/Nimble @ 3720e6b0f6de6d6435f79f8a174fb4bb92df5dc4
2017-03-14 14:11:40.794 carthage[57473:2028920] complete clone submodule Carthage/Checkouts/Quick @ e4fa1e85c0305ba4e0866f25812d3fa398f3a048
2017-03-14 15:01:01.880 carthage[57473:2180717] complete clone submodule Carthage/Checkouts/ReactiveSwift @ c83de32f1adbcef89618cde4222f69a8bcecd7c2

```

We can see most of the time is spent cloning submodules, and the largest submodule is ReactiveSwift. But at the second line of log checking out ReactiveSwift itself only takes a few seconds. And also some submodules are duplicated, both ReactiveSwift and ReactiveCocoa have Nimble, Quick, Result, and xcconfigs as their submodules.

Many libraries are using submodules for managing dependencies, thus many of the submodules are already fetched in the Carthage cache. I believe at least cloning of these submodules can be optimized.

Start at the `cloneSubmoduleInWorkingDirectory` signal producer used during `carthage checkout --no-use-binaries`, then trace how submodules are handled for ReactiveSwift and ReactiveCocoa. Reproduce the repeated cloning shown in the issue and inspect how the Carthage cache is consulted. Done means checkout avoids unnecessary duplicate submodule work while preserving the requested revisions.

Written by the indexing model from the issue text.