Decouple summarizer and code generator

[mahesh-hegde]

Motivation:

• The source based summarizer is slow, especially on low end machine. This makes jnigen end-to-end tests take much more time than that of ffigen.

• We should be able to test the summary generation easily, and also be able to add tests which ensure both parsers generate similar information.

• Ideally, we should be able to either cache the summary, or pass the same summary to different tests. Test bindings using both Dart-only and Dart+C modes #685

• Ideally, adding a new parser should be easier in future. For example, to parse kotlin sources, or to parse incomplete java sources.

Design 1: caching summary

• summary is cached in .dart_tool/jnigen/summary-{config_hash}.
• It's invalidated when any .java file in source_path or .jar or .class file in class_path is newer than the cached summary, or related config is modified.
• When there are more than, say, 5 summary caches, least recently used one is evicted, (or upon a hash collision).

Design 2: Explicitly dumping and passing summary

This is a simpler design.

• jnigen:write_summary file --config=... writes summary to specified file

• jnigen ..... --summary-file= reads the summary from specified file instead of parsing.

Other tasks

• Ensure overload-renaming order is same with any parser. This can be achived by some sorting in proper place.

[mahesh-hegde]

I think as @HosseinYousefi mentioned elsewhere, it's better to test each part of the pipeline separately. Separating getSummary() part in code is trivial and dart-archive/jnigen#220 already does that to enable some tests. So closing this as not planned.