We consider an entry in .gitmodules to mean that we have a submodule at
a particular path, even if HEAD^{tree} and the index do not contain any
reference to it.

We should ignore that submodule entry and simply consider that path to
be a regular directory.

When we mention "src" in src/.gitignore, we wrongly consider src/ itself
to be ignored.

We currently consider CR to start the end of the line, but that means
that we miss cases with CR CR LF which can be used with git to match
files whose names have CR at the end of their names.

The fix from the patch comes from Russell's comment in the issue.

This fixes #2536.

Fix bugs with negative ignores inside an ignored parent directory

`git help ignore` has this to say about trailing slashes:

> If the pattern ends with a slash, it is removed for the purpose of
> the following description, but it would only find a match with a
> directory. In other words, foo/ will match a directory foo and
> paths underneath it, but will not match a regular file or a
> symbolic link foo (this is consistent with the way how pathspec
> works in general in Git).

Sure enough, having manually performed the same steps as this test,
`git status` tells us the following:

	# On branch master
	#
	# Initial commit
	#
	# Changes to be committed:
	#   (use "git rm --cached <file>..." to unstage)
	#
	#	new file:   force.txt
	#
	# Untracked files:
	#   (use "git add <file>..." to include in what will be committed)
	#
	#	../.gitignore
	#	child1/
	#	child2/

i.e. neither child1 nor child2 is ignored.

When writing 'bin/*' in the rules, this means we ignore very file inside
bin/ individually, but do not ignore the directory itself. Thus the
status listing should list both files under bin/, one untracked and one
ignored.

Conflicts:
	include/git2/diff.h