simplify method hasDotGitSubfolder

Hello Sergei,

this one I just couldn't resist to improve.

Anyways, my real point is this:
I'm working on a next version of tc_java, the java plugin for TotalCommander, and looking for good examples as well as (maybe?) collaborators.
It's about adding an API to it that 
* feels more java-like
* offloads tedious and error-prone stuff from the plugin developer, as to both, make the actual plugin code more concise/compact and also more robust.

Your GitDetails plugin is a very nice idea and I think it would make for a great example.
Next, it could already profit from using my API, even though it (the API) is in a very early and premature stage (!).
This last thing I have to emphasize, it's really very early, not even properly organized. In fact, I'm looking for feedback from actual plugin writers as to how to best organize it.

By skimming over your code I found some questionable things that just would have been solved for you by the API:
* bug: FT_NOMOREFIELDS is returned from contentGetValue where it should be FT_NOSUCHFIELD
* problematic: non-thread-safe use of instance variables gitRepo and gitRepoFileName, used for caching. Another thing is that TC has *two* panes, as you know, which a caching strategy should take into consideration (tricky, though).
* problematic: you're registering all values from your `Columns` enum but are actually serving only three
* ?: from these three, `BRANCH_NAME`, `ORIGIN_URL`, `UPSTREAM_URL`, TC offers me only the first two. `UPSTREAM_URL` is missing. Don't know why...

Plz don't take this as an offense, I'm just trying to advertise. And I do like your plugin :)
Plus: I'm hoping to get you interested. Let me invite you to participate in ["Let's make writing Java plugins fun!"](http://ghisler.ch/board/viewtopic.php?t=39016) on the TotalCommander forum.

Should you prefer github instead, that's fine too. I'll be grateful for any answer :)

Cheers,
meisl