Fix for bug #927. Ignore package if name matches specified in bower.json.
Permit fetch if package is explicitly declared in dependencies or devDependencies.
Designed for users who need tighter control of versions due to corporate liscence restrictions or other reasons.
Code Review Comments
Prior to this commit, when specifying a package version that cannot
be resolved, but other versions are available, the error message
did not state which what package failed, allowing for confusion.
For example, you might see:
```
bower ENORESTARGET No tag found that was able to satisfy 1.0.2
Additional error details:
Available versions: 1.0.1, 1.0.0
```
After this change, in the above situation the svn and git resolvers
will produce the following:
```
bower ENORESTARGET No tag found that was able to satisfy 1.0.2
Additional error details:
Available versions in somelib: 1.0.1, 1.0.0
```
A change in the behavior of `mout.lang.isEmpty()` in Mout v0.10.0
introduced a bug in `bower init`, preventing it from including Boolean
values in "bower.json".
This commit explicitly whitelists the types that are used in the
bower.json spec - Object, Array, String, Boolean - as well as Number for
future compatibility.
When users of the programmatic API update the version, they may do so without having to inspect the new contents of the bower.json file to find out the new version.
This is useful in scripts where the tag needs to be pushed programatically; the user can push the new tag explicitly.
Added logic to automatically detect smart Git hosts that allow shallow
cloning. This is done by sending an `ls-remote` request to the server
and then evaluating the returned HTTP header fields. For this, Curl
verbose logging is enabled for the `ls-remote` request, since Curl
verbose logging sends the returned HTTP headers to `stderr`.
If the `stderr` output contains the desired header
Content-Type: application/x-git-upload-pack-advertisement
then the server supports shallow cloning.
This approach uses Git and Curl for the heavy lifting. Instead of
implementing the request to the server using a simple HTTP client, Git
is used, since it takes care of authentication using stored credentials.
The used approach should also work for BitBucket, which only sends the
Content-Type header when a specific user agent is used. Using Git to
make the request enables this behavior.
The function to detect the smart Git host
(`GitRemoteResolver.prototype._supportsShallowCloning`) returns a
promise that is resolved when the server's request is evaluated. The
promise handling required an addition to `GitHubResolver.js` - to always
resolve the promise to `true`, since GitHub supports shallow cloning.
Added test cases to verify the new functionality.
