refactor: treat --sub-project option like --file option, as defaultProj

[magdziarek]

• [ ] Tests written and linted
• [ ] Documentation written
• [ ] Commit history is tidy

What this does

• --file and --sub-project have the same purpose, when used from a root directory they allow to analyze only one target project, however currently we treat them differently
• this should prepare ground for changes in project identification - using path (unique value) instead of name as we sometimes see duplicates of names in multi module builds

Notes for the reviewer

The change does something to the rootPkg.name value, therefore there are some commented lines in multi-project.test.ts. The test doesn't look reliable - the results for the test with --sub-project set where the --sub-project value needs trimming should be the same as for when it's not trimmed. Where is rootPkg used and can we change it?

Don't think this is how we should set the projectName because this is not a reliable way to determine if project is a subproject (in case there are duplicates) and I am not sure why we want this format of name (a path from root?) - does this matter for anything?

    const isSubProject = projectId !== defaultProject;

    let projectName = isValidRootDir ? path.basename(root) : defaultProject;

    if (isSubProject) {
      projectName = isValidRootDir
        ? `${path.basename(root)}/${projectId}`
        : `${defaultProject}/${projectId}`;
    } 

[ghost]

This PR modifies files linked to issues tracked in Stepsize. You might want to review their status, priority, and scope.

Use Lenient Configuration by default

- `lib/init.gradle`

_{Mention [stepsize] in a comment if you'd like to report some technical debt. See examples here.}