Incorrect stripes-core reported with mod descriptor command

When running stripes mod descriptor, the CLI will invoke the stripes-core's StripesModuleParser. This uses a helper function from module-paths.js named locateStripesModule() which gives preference to the stripes-core invoking the script.

  // If we are looking for anything in stripes-core, then we are already there!
  if (moduleName === '@folio/stripes-core') {
    tryPaths.unshift({
      request: path.join(__dirname, '..', ...segments),
    });
  }

However, when the module parser is imported in the CLI's module-service.js, the CLI's instance of stripes-core is used which could differ from that used by an app or platform.

const parser = require('@folio/stripes-core/webpack/stripes-module-parser');

This causes the wrong module descriptor to be generated for the mod descriptor command (as well as new backend install functionality being worked on in STCLI-15)

This is an issue for globally installed CLIs as well as a local clone used for CLI development. It should not be an issue when the CLI is used as a devDependency of an app or platform as presumably they will share the same version of stripes-core.

The CLI already has functionality to give preference to the app or platform's stripes-core for build and serve functionality. The same logic should be applied here as well.