The UseAppCDS flag was useful in the old days when AppCDS feature was in the closed and and we wanted a separation of the feature from the basic CDS. Now AppCDS is in the open, UseAppCDS flag is no longer serving its original purpose and complicates code unnecessarily. The behavior of CDS/AppCDS should be determined by the content of the class list at dump time and the content of the archive file at runtime.

The benefits of removing the UseAppCDS flag:
1. Cleaner code
2. Less confusion in the community about CDS and AppCDS. AppCDS is CDS but with app classes supported in the archive. It adds extra complexity to force the separation of the two.
3. Simpler usage, which will result more adoption.

SharedArchiveFile option
---------------------------------
The -XX:SharedArchiveFile is a product flag when UseAppCDS is enabled, but is a diagnostic flag when UseAppCDS is disabled. As a result of making UseAppCDS obsolete, SharedArchiveFile will become a product flag by default. Specifying +UnlockDiagnosticVMOptions for SharedArchiveFile will no longer be needed in all configurations.

Non-empty directory handling
---------------------------------------
CDS/AppCDS reports error for non-empty directory:
- For base CDS, non-empty directory cannot exist in -Xbootclasspath/a path
- With AppCDS enabled, non-empty directory cannot exist in -Xbootclasspath/a path, class path, and module path

After making UseAppCDS obsolete, the behavior for non-empty directory handling will be based on class type on the classlist:
- If no app classes are loaded, dump time only reports error if non-empty directory exists in -Xbootclasspath/a path
- If app classes are loaded, dump time reports error for non-empty directory exists in -Xbootclasspath/a path, class path, or module path

Above behavior is backward compatible.