Handle workspaces with multiple build files.

[ckipp01]

Previously this always defaulted to the first found, many times leading
to an SBT build if a workspace had both a build.sbt and a build.sc
file. Now both are grabbed and the user is prompted to choose whether
the space if for build tool A or build tool B. This choice is remembered
and they are not asked about this again.

Demo

Chosen Approach

I went back and forth on how the flow should go for this. I really wanted that when it was detected that multiple build definitions were found that it'd prompt like the following:

New workspace found. Would you like to import:?
1. Import sbt build
2. Import mill build
3. Not now
4. Don't show again

However, after doing that it was quite messy since you have to carry a list of BuildTool round to multiple methods, which all would have to handle if there was one more many. I found it way simpler and less of a change to simply prompt the user right away when multiple were found to get their intention for the workspace. Then all of the rest of the logic can remained unchanged. I'm still open to the alternative way that I outlined I guess, but I really think it will messier and more code without much benefit.

All that to say, I wanted to throw this up here to make sure this approach was ok before I started to write tests for this.

Closes #1757

[tgodzik]

I added some small comments, but I think it's a good direction. Both versions you proposed seem OK to me and if this causes less changes then I don't think we should go the other way.

[ckipp01]

I added some small comments, but I think it's a good direction. Both versions you proposed seem OK to me and if this causes less changes then I don't think we should go the other way.

Sounds good 👍 I'll keep going this route then.

[kpbochenek]

Cool improvement! 👍

Can we also have a possibility to see which build system was used for import?
Maybe in a Metals Doctor? Just random thought.

A db will not be wiped when I do "Build import", right? It would be good to give user an option to reset chosen build tool, what do you think?

[ckipp01]

Cool improvement! 👍

Can we also have a possibility to see which build system was used for import?
Maybe in a Metals Doctor? Just random thought.

Ah, I hadn't thought of that, but yea, that's a cool idea. Let me play around with this to make sure there is a good minimal way to display this.

A db will not be wiped when I do "Build import", right? It would be good to give user an option to reset chosen build tool, what do you think?

Yea the decisions is persisted, so currently, apart from delete the .metals/ directory, there wouldn't be a way to reset this. However, this is sort of a problem that exists in multiple other message requests as well though right?

[kpbochenek]

Yea the decisions is persisted, so currently, apart from delete the .metals/ directory, there wouldn't be a way to reset this. However, this is sort of a problem that exists in multiple other message requests as well though right?

You are probably right, I don't know how it works for other messages 😅

[ckipp01]

If a user has two build definitions and they had to choose one, a short message will be added to their doctor output just saying Your <build tool> build definition has been imported. Here is an example:

[tgodzik]

Thanks for the great work! I have just two minor comments, but I would like to merge the Ammonite PR first, since it can have conflicts with this one.

[ckipp01]

I would like to merge the Ammonite PR first, since it can have conflicts with this one.

No worries! I figured there would be some conflicts. I'll rebase once it's merged.

[tgodzik]

LGTM! Let's merge this and I will follow up with the import formatting PR