Support diffing Jar bytecode versions

[Goooler]

OLD: diffuse-0.2.0-SNAPSHOT-java11.jar (bytecodeVersion: 55)
NEW: diffuse-0.2.0-SNAPSHOT-java16.jar (bytecodeVersion: 60)

 JAR   │ old      │ new      │ diff
───────┼──────────┼──────────┼──────
 class │ 90.6 KiB │ 90.6 KiB │  0 B
 other │     96 B │     96 B │  0 B
───────┼──────────┼──────────┼──────
 total │ 90.7 KiB │ 90.7 KiB │  0 B

 CLASSES │ old │ new │ diff
─────────┼─────┼─────┼───────────
 classes │  24 │  24 │ 0 (+0 -0)
 methods │ 234 │ 234 │ 0 (+0 -0)
  fields │  78 │  78 │ 0 (+0 -0)

=================
====   JAR   ====
=================

 size │ diff │ path
──────┼──────┼─────────
  0 B │  0 B │ (total)

[Goooler]

I'm not sure how to implement this for Dex files.

[JakeWharton]

Unfortunately I think we're going to drown in nuance here. Jars don't have bytecode versions, classes do. And multiple classes within a jar can have different versions. You can conditionally classload classes based on capabilities and those classes could be compiled for two different versions of Java. There's also the multi-version jar standard which puts classes of different versions into META-INF/versions/N/. The ordering of the classes in the jar (read: zip) could be effectively random so taking the first class may not be indicative of what the majority of classes were compiled with.

I'm happy to discuss strategies for surfacing this information, but as-is I think this is too simple of an implementation. Note that it probably works for 99.99% of jars, but when it fails it fails in a spectacularly wrong way.

[Goooler]

Now I count all the byte code versions in a Jar and filter the most one.

[Goooler]

Addressing a new fix to #473.