JavaSourceUiDescriber scans the entire document to detect GUI files; should be bounded

[lyh061619]

Body:
WindowBuilder registers a by-contents content describer (JavaSourceUiDescriber)
that reads the whole file to look for GUI markers. Most describers inspect only
a prefix; this one makes EVERY content-type query on a large file O(file size).

(Stack: see LSP4E issue 3a — org.eclipse.wb.internal.core.editor.describer.
JavaSourceUiDescriber.describe called via ContentTypeCatalog.describe on every
LSP4E query.)

Expected: bound the scan (e.g. first N KB) or use a cheap heuristic first.

[ptziegler]

I don't think there really is a "cheap" heuristic to determine, whether a file contains UI components. But I believe there are a couple of things that could be made more efficient.

When all WindowBuilder plugins are installed, the complexity of the algorithm is O(6n), with n being the length of the document. Once, because the entire document is copied to a string and once for each pattern. With e.g. the Aho-Corasick algorithm, this can be reduced to O(n+m), with m being the length of the longest pattern.

As an additional step, one could also only look at the import statements. So we only look until we find the type definition. E.g. the first occurrence of class, record or enum. Or perhaps even just {. There's still be an issue if all UI classes are referenced by their fully-qualified name instead of being imported, but I highly doubt that's the common use case.

[vogella]

Patterns could also be cached, see #1653