Refactor CDS classpath validation checks

The CDS classpath validation checking code has evolved over time and become difficult to maintain. It's also hard to tell from the code what the rules are for accepting or rejecting a runtime classpath.

We should refactor the code to make it simpler and easier to understand.

(1) Decouple classpath validation from FileMapInfo::shared_path(index), because this function depends on expanded Class-Path: attributes, which makes validation more complicated.

(2) Define a new concept: "effective combined cp": this is essentially a concatenation of

    Arguments::get_jdk_boot_class_path_append() + ":" + Arguments::get_appclasspath();

However, all non-existent files are excluded. E.g., if running with:

    java -Xbootclasspath/a:nosuchfile.jar:foo.jar:nosuchfile.jar -cp a.jar:nosuchfile.jar:b.jar

the ECCP is

    foo.jar:a.jar:b.jar

(3) Add a new function that can be called at both runtime and dump time:

    GrowawableArray<char*> get_effective_combined_cp_upto(int n);

    In the above example, get_effective_combined_cp_upto(1) returns {"foo.jar", "a.jar"}
    
(4) In FileMapHeader, add a new data structure FileMapHeader::_effective_combined_cp that saves get_effective_combined_cp_upto(max_effective_combined_cp), where max_effective_combined_cp is calculated from FileMapHeader::_max_used_path_index, but we skip all the entries whose (_from_class_path_attr == true)

(5) At runtime:

    runtime_eccp = get_effective_combined_cp_upto(FileMapHeader::_max_used_path_index);

Check that runtime_eccp matches with FileMapHeader::_effective_combined_cp