Add .mill.sc as an alternative file extension to .mill

[lihaoyi]

Took a bit of fiddling because we had to stop using os.Path#ext because it only takes the last segment, and also now one of the extensions is a suffix of another. There will likely be a short tail of bugs that arise because of this, but it shouldn't be too burdensome to resolve them. Otherwise this functionality should be relatively cheap to add and maintain since we already have the extensions and file names centralized in CodeGenConstants.java.

This is a compromise between .mill and .mill.sc. I still believe long term .mill is better, but I can believe that short term pain of having everything not understand your .mill extensions is painful. This lets people use .mill.sc where preferable, and .mill otherwise by default. I expect long term .mill will be superior once all the tooling has caught up, but until then people can use .mill.sc if they want the generic .sc Scala script support that many tools use.

Having two extensions isn't that unusual, e.g. Bazel supports both BUILD and BUILD.bazel as file extenions, supported indefinitely. The cost of adding two extensions isn't significantly more than the cost of adding one: in any case we need to send PRs to the various tools, and a PR adding two extensions isn't any more difficult than a PR adding one.

Added an example test 13-helper-files-mill-sc, variant of 11-helper-files, which should exercise most of the file discovery/import/codegen/etc. logic that may be impacted by the extension

[lefou]

Kudos for being open to support .mill.sc as an alternative extension to .mill!

Having the alternative is probably not ideal and will cause friction since projects will eventually encounter contributors preferring the other version. But we're still experimenting, so it's good to keep any bit of editor support we can get.

[lihaoyi]

My attempts to deal with CI flakiness have gotten a bit out of hand, but hopefully I'll be able to stabilize this enough to get a solid green build