Set default name for settings file as `project.scala`

Describe what needs to be done and why In case of multiple files it might be useful to allow the user to specify all the using directives in a central file as one would expect similarly to build tools.

There was multiple discussions about what the name should and it seems the winning vote was on project.scala

We need to probably do a number of things:

• warn users about multiple using directives and suggest using project.scala
• automatically detect project as ScalaCLI in Metals when project.scala is present
• create a g8 template with project.scala and also add it to new project wizard in Metals
• add an automatic action to move all actions into project.scala
• fix tapir templates to use project.scala
• update all existing references in our docs from project.settings.scala to project.scala

This issue can act as a central point coordinate the work being done.

Nice to have:

• automatically detect project as ScalaCLI in Intellij when project.scala is present
• the existing docs on project.settings.scala seem to have been confusing to some users, so probably improve the docs a bit
  • we probably need a dedicated, small doc on this in the Guides section
  • the Project root directory doc should link to the aforementioned guide
• Once all else is done, we probably should enable migrating directives to project.scala automatically with a sub-command, as our docs are implying we’ve been planning to do that for a long while.

[tgodzik]

Thanks! Added to the description.

[tgodzik]

@tusharmath Thanks for the suggestion!

The plan currently is to only allow using directives a.k.a //> using... and project.scala just allows users to specify everything in a well defined single place without forcing everyone to use it. If we choose to enable json configuration that would mean that we would have 3 sources of truth: CLI args, using directives and json configuration, which will be very difficult to maintain and make sure that works well out of the box for most people. This is not a direction we want to take, but really thank you for your input! It’s really good to have a discussion about the finer points of ScalaCLI design decisions.