`spago update` command should work with solver-packages too

[f-f]

When the project build happens with the solver (rather than package sets), we should:

1. try to build a plan with the latest versions on the Registry that are still compatible with the current compiler
2. build with that plan
3. and if all is well put the new ranges in the config file

[f-f]

Pivoting this issue to solver-projects only, since the package sets side is done

[f-f]

I think the solver will try to pick latest dependencies first, so it might be good enough to:

• park away the current ranges
• ask the solver to give us a plan with the widest ranges
• union the old ranges with the new ones

I think this is blocked by ~~#1003~~ #917, because we should update the lockfile when the plan is good - right now we don't use the lockfile in the right way, and there are no tests for it.

[flip111]

label size:medium seems more applicable to me. Or perhaps somebody can provide some pointers to this issue?

[f-f]

What I really mean with the size:small label is "under 50 lines" (this one might be slightly bigger than that, but the spec is very clear so I think it's affordable) - some patches are 5-10 lines, and that would deserve a size:micro label 😄

A few pointers for this:

• the unimplemented branch is here, so you can replace this error with the new code: https://github.com/purescript/spago/blob/b450892d69aa3013861fde6c73299d2c17aba3dc/src/Spago/Command/Upgrade.purs#L26
• upgrading the package set is about the whole workspace, but for upgrading solver ranges we want to deal with a single package/config file, so we'll want to select a single package like this: https://github.com/purescript/spago/blob/b450892d69aa3013861fde6c73299d2c17aba3dc/bin/src/Main.purs#L753-L767
• at this point you can look inside this selected :: WorkspacePackage, and get its Dependencies. Hold on to them because you'll need them later (e.g. in a currentDependencies variable)
• then create new ranges for the solver run, where you take the currentDependencies, and just assign the Config.widestRange to every package
• ...so you can call the solver to get a new plan: https://github.com/purescript/spago/blob/b450892d69aa3013861fde6c73299d2c17aba3dc/src/Spago/Command/Fetch.purs#L460
• if the plan is bad then fail with the error, but if it's good we can overwrite the current ranges in the config file, as we do for the ensureRanges flag (note the call to getRangeFromPackage, we'll want to union the old Range in currentRanges with the new Range that we get from this function): https://github.com/purescript/spago/blob/b450892d69aa3013861fde6c73299d2c17aba3dc/src/Spago/Command/Fetch.purs#L162-L170