*
 * <ul>
 *   <li><b>Shallow immutability.</b> Elements can never be added, removed or replaced in this
 *       collection. This is a stronger guarantee than that of {@link
 *       Collections#unmodifiableCollection}, whose contents change whenever the wrapped collection
 *       is modified.
 *   <li><b>Null-hostility.</b> This collection will never contain a null element.

   *
   * <ul>
   *   <li>All NaNs are fuzzily equal.
   *   <li>If {@code a == b}, then {@code a} and {@code b} are always fuzzily equal.
   *   <li>Positive and negative zero are always fuzzily equal.
   *   <li>If {@code tolerance} is zero, and neither {@code a} nor {@code b} is NaN, then {@code a}
   *       and {@code b} are fuzzily equal if and only if {@code a == b}.

 * instances:
 *
 * <ul>
 *   <li>If you receive them from an {@code java.util.concurrent.ExecutorService}, convert that
 *       service to a {@link ListeningExecutorService}, usually by calling {@link
 *       MoreExecutors#listeningDecorator(java.util.concurrent.ExecutorService)
 *       MoreExecutors.listeningDecorator}.
 *   <li>If you manually call {@link java.util.concurrent.FutureTask#set} or a similar method,

     * <p><b>Algorithm:</b>
     * If the given path is a directory, then there is a choice:
     * </p>
     * <ul>
     *   <li><b>Package hierarchy:</b> if a {@code module-info.class} file is found at the root,
     *       then builds a singleton map with the module name declared in that descriptor.</li>
     *   <li><b>Module hierarchy:</b> if {@code module-info.class} files are found in sub-directories,

 *
 * <p>For instance, if <i>steps</i> is 5, one example sequence that will be tested is:
 *
 * <ol>
 *   <li>remove();
 *   <li>hasNext()
 *   <li>hasNext();
 *   <li>remove();
 *   <li>next();
 * </ol>
 *
 * <p>This particular order of operations may be unrealistic, and testing all 3^5 of them may be

 *
 * <ul>
 *   <li><b>Shallow immutability.</b> Elements can never be added, removed or replaced in this
 *       collection. This is a stronger guarantee than that of {@link
 *       Collections#unmodifiableCollection}, whose contents change whenever the wrapped collection
 *       is modified.
 *   <li><b>Null-hostility.</b> This collection will never contain a null element.

   * }</pre>
   *
   * <p>returns a set containing six lists:
   *
   * <ul>
   *   <li>{@code ImmutableList.of(1, "A")}
   *   <li>{@code ImmutableList.of(1, "B")}
   *   <li>{@code ImmutableList.of(1, "C")}
   *   <li>{@code ImmutableList.of(2, "A")}
   *   <li>{@code ImmutableList.of(2, "B")}
   *   <li>{@code ImmutableList.of(2, "C")}
   * </ul>
   *

     *     </ul>
     *   </li>
     *   <li>Otherwise (test output contains no module information), then:
     *     <ul>
     *       <li>If the main output is on the module-path, place the test output
     *           on a {@code --patch-module} option.</li>
     *       <li>Otherwise (main output on the class-path), place the test output on the class-path too.</li>
     *     </ul>
     *   </li>

   *   <li>If there is any non-private constructor or non-private static factory method declared by
   *       {@code cls}:
   *       <ul>
   *         <li>Test will fail if default value for a parameter cannot be determined.
   *         <li>Test will fail if the factory method returns null so testing instance methods is
   *             impossible.

     * </p>
     * <ul>
     *   <li>If {@link #MODULES} path type is also set, then the dependency can be placed either on the
     *       class-path or on the module-path, but only one of those. The choice is up to the plugin,
     *       possibly using heuristic rules (Maven 3 behavior).</li>
     *   <li>If a {@link #patchModule(String)} is also set and the main JAR file is placed on the module-path,