When annex.thin is set, allow hard links to be made between executable work tree files and annex objects.

This is safe, because while the annex object ends up executable,
there were already at least two other cases where it ended up executable:

1. git add an an executable file
2. chmod +x of a a non-executable worktree file that was hard linked to the
   annex object

After copy/hard link, it always fixes up the permissions to match the mode
of the worktree file, so when an executable annex object gets hard linked
to a non-executable worktree file, its execute bit gets removed.

Commit b7c8bf5274 already *said* it would do
this; I suspect the line of code I've removed was included in that commit
accidentially.

Also improves annex.thin documentation.

This commit was sponsored by Boyd Stephen Smith Jr. on Patreon.

doc/bugs/v6_hardlinking_is_not_stable_across_lock__47__unlock_or_cloning.mdwn

@@ -377,3 +377,5 @@ total 12
 lil' positive end note mode on:
 
 git-annex is the only thing to which I trust my archive of most valuable documents and memories!
+
+> [[done]]; see comments --[[Joey]]

doc/bugs/v6_hardlinking_is_not_stable_across_lock__47__unlock_or_cloning/comment_4_41478c52765cf09a94c7137437ad8716._comment

@@ -5,6 +5,7 @@
  subject="comment 4"
  date="2018-10-18T23:34:26Z"
  content="""
+
 I am stupid talking about executable files hardlinking. I think I just chmod-ed already hardlinking files, that's how I got it. No surprise.
 
 I am ok with this quirk (executable files are not thinned), but just curious: what exactly influenced such design decision?

doc/bugs/v6_hardlinking_is_not_stable_across_lock__47__unlock_or_cloning/comment_5_2b36163f3c8cca18ce4b05e381bf1795._comment

@@ -0,0 +1,24 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2018-10-26T17:17:35Z"
+ content="""
+[[!commit b7c8bf5274a64389ac87d6ce0388b8708c261971]] is where that was
+implemented. Interestingly, its commit message does say that the annex
+object file is made executable when using annex.thin.
+And indeed, git add of an executable file with annex.thin set does
+make the object executable and hard link to it.
+
+But that commit contains this line that avoids hard linking:
+
+	        | maybe False isExecutable destmode = copy =<< getstat
+
+Which is what I based my earlier comment on. But without that line,
+AFAIK it will behave the way you want, with the annex object and
+executable worktree file being hard linked. The code also removes the
+execute bit if the annex object file later ends up getting hard linked
+instead to a non-executable file.
+
+So, based on this analysis, I'm going to remove that line. And improve the
+annex.thin docs slightly, and I think that's sufficient to close this bug.
+"""]]