Warn when `--exclude`/`//> using exclude` does not actually exclude any files from the project

[Gedochao]

Version(s)
1.5.4 and 4ab3227

Describe the issue
When declaring a path or pattern in --exclude///> using exclude, I'd like a warning if no sources were actually caught by the pattern I declared. This would make it easier to catch when my exclusion actually works.
Additionally, I'd like some debug logs under -v -v -v telling me which files were, in fact, excluded.

[Gedochao]

Should start investigating at:

• scala-cli/modules/build/src/main/scala/scala/build/CrossSources.scala

  Lines 192 to 200 in bf3753e

  	val allExclude = { // supports only one exclude directive in one source file, which should be the project file.
  	val projectScalaFileOpt = flattenedInputs.collectFirst {
  	case f: ProjectScalaFile => f
  	}
  	val excludeFromProjectFile =
  	value(preprocessSources(projectScalaFileOpt.toSeq))
  	.flatMap(_.options).flatMap(_.internal.exclude)
  	exclude ++ excludeFromProjectFile
  	}

[SethTisue]

I'd like some debug logs under -v -v -v telling me which files were, in fact, excluded

I suggest we start here, as the lack of this seems like a straight up bug to me. At maximum verbosity, the tool ought to be telling me what it's doing.

[SethTisue]

@MaciejG604 and I worked on this today at the Tooling Spree

wip code at https://github.com/SethTisue/scala-cli/commits/issue-3387/

the branch includes a ./test directory for manual testing with ./mill -i scala compile -v -v --exclude U.scala test, so we have one exclude coming from the command line and one coming from the //> using exclude S.scala in project.scala. a finished PR wouldn't include that

as Piotr indicated, all of the relevant code is in CrossSources.scala, I don't think any changes will be needed elsewhere

the wip code:

• does the logging but it's doubled
• tries to do the warning but it's incorrect (and we ran out of time trying to figure out why)

this got more complicated than expected because of the way the existing code is structured. in particular

• excludeSources is called three times (by forInputs), but we only want to do any logging once
• at the end of excludeSources, we loop over the files and apply all the filters together to each file — but that's the inverse of the logic that would make the warning easy to produce, since the warnings are per-filter
  • in the WIP code, in the interest of time we do the warnings in a separate pass. it's an open question whether the two passes can elegantly be condensed into a single pass

so some refactoring/restructuring is needed in order to solve this elegantly

in a finished PR I think the logging part probably doesn't need automated testing but the warning part should have it