Support build-wide configuration for many custom Maven/Ivy repositories

[jvican]

Is your feature request related to a problem? Please describe.

When using scala-cli in companies that require custom Artifactory repositories, it is kind of cumbersome to define these repositories (sometimes two or three very long strings because they encode the maven/ivy patterns) because one either needs to:

1. Define them with using on all Scala files in the build; or,
2. Add them in every scala-cli invocation3.

Both of those require lots of ceremony and are a bit annoying. Can we have a better way of doing this?

Describe the solution you'd like

There are different ways of getting around this, but one quickly figures out that what I'm asking for is some kind of build-wide configuration mechanism. I realize that having the build configuration be in Scala source files is very much intentional and I like to think of that as one of the main defining aspects of scala-cli. Thus, I think there are two approaches that would be best:

1. Define .scala-cli-config that allows you to pass in default scala-cli arguments that will always be picked up by scala-cli
2. Allow to use //> using comments in a Scala file called build-defaults.scala where people can add using defaults

This way, I would add the repository information to either of those places and I'd be able to avoid them everywhere else. This can also help defining defaults that need to be used build-wide that are not related to dependency resolution.

Additional context

I believe having something like this would make scala-cli much more appealing and easier to use in companies/enterprises, where the use of internal repositories is common.

[alexarchambault]

Coursier mirrors ought to work from Scala CLI, and do just that (if the mirroring repo is a Maven one, at least).

[Gedochao]

Seems to be largely covered by coursier. Maven configuration files can also be used by coursier, as described under https://scala-cli.virtuslab.org/docs/guides/power/proxy#maven-configuration-file More docs should be done though, to be tracked under #1109