## Description
CLI cannot find liquibase.properties inside jar file with resources

## Steps To Reproduce
* put liquibase.properties inside jar file with database changelog and chagesets. in my case it is DatabaseUpdateResources.jar
* replace path to liquibase.jar, database driver jar and jar with resouurces in command below and run it
* java -cp "${path_to_jar}\liquibase.jar;${path_to_jar}\DatabaseUpdateResources.jar;${path_to_database_driver_jar}{database_driver.jar}" liquibase.integration.commandline.Main --logLevel=info update

## Actual Behavior
Errors:
The option --url is required.
The option --changeLogFile is required.

## Expected/Desired Behavior
liquibase used options from liquibase.properties inside jar in classpath.

## Additional Context
in version 3.5.3 cli update with properties file in jar worked correctly, this problem happened after updating to 4.2.0.

Issue created from original PR #1545


import java.net.URL;
import java.net.URLClassLoader;
import java.nio.file.Paths;
import java.security.AccessController;
import java.security.PrivilegedAction;
import java.util.*;
import java.util.logging.*;
import java.util.stream.Collectors;
import java.util.stream.Stream;
import static java.util.ResourceBundle.getBundle;
import static liquibase.util.SystemUtil.isWindows;
public class LiquibaseCommandLine {
    private final Map<String, String> legacyPositionalArguments;
    /**
     * Arguments that used to be global arguments but are now command-level
     */
    private final Set<String> legacyNoLongerGlobalArguments;
    /**
     * Arguments that used to be command arguments but are now global
     */
    private final Set<String> legacyNoLongerCommandArguments;
    private Level configuredLogLevel;
    private final CommandLine commandLine;
    private FileHandler fileHandler;
    private final ResourceBundle coreBundle = getBundle("liquibase/i18n/liquibase-core");
    /**
     * Pico's defaultFactory does a lot of reflection, checking for classes we know we don't have.
     * That is slow on older JVMs and impact initial startup time, so do our own factory for performance reasons.
     * It is easy to configure pico to it's default factory, when profiling check for `CommandLine$DefaultFactory` usage
     */