[class-parse] really support Java8 and other various doclet types.

[atsushieno]

ClassPath class had a red-herring property named "DocletType", which was
NEVER assigned and therefore never worked. Its existence is optimistic
so that it premised that any consuming code knows which doclet type its
argument javadoc is generated with.

So, just kill it and implement working code here.

Now that we get a working doclet parser, a handful of Java8 scraper issues
were discovered, so fixed them all. Namely:

• Arrays are replaced as :A, not mere [].
  • the new DroidDoc actually uses [] as is, and I believe it used to be
    so too in Javadocs. On the other hand, [] may show up only within
    droiddocs, so skip that string.Replace() for Java8.
• Java8 doc parsers simply passed '-' which actually needed to be escaped.
  It caused errors when argument names were simple like 'x-y' (which was
  treated as character range specification in regex).
• regex matching for "anything except for '('" should actually be
  "... except for '(' and ')'" and then they should have been escaped too.

[jonpryor]

So, just kill it and implement working code here.

I for one welcome our working code overlords.

That said, The Immortal Questions:

1. Is this unit testable? If it isn't unit testable, there needs to be a good description for why.
2. Let's see some unit tests? :-)

[atsushieno]

No.

Those javadocs that are used in real productions are written in quite complicated HTML structure that I don't think there is reliable way to write by our own. And those javadocs are copyrighted. That's why it was never tested.

What we can do instead is to download those existing javadocs at test-run-time and see if it generates parameter names as expected (which by the way still does not likely: this incomplete ClassParse functionality had blocked us (me) from doing any implementation sanity check). I think such tests are going to take a lot of time (like our msbuild tests do).

And then, having this PR blocked until those lengthy testing means that our component team will never get the entire simplified binding tooling improvements JUST FOR THIS. I don't think it is welcomed situation.