Improve the user experience for Go workspaces

[brunoapimentel]

Currently, when a user has workspaces in his repository, he still needs to specify the path to a specific Go module when creating a Cachi2 request. If the specified path only has a go.work file (and no go.mod file), the request would fail.

This also brings some code design implications: for historical reasons, Cachi2 uses the concept of a "main module" when processing a repo, which is the module that exists in the path specified by the user when creating the request. If multiple paths were specified, then each of them will be a "main module" during the iteration across all these paths.

With the addition of workspace support, this concept falls flat: there is no real "main module" in a project with workspaces, but instead, a collection of equally important modules.

We should:

• refactor the code to get rid of the concept of a main module
• allow the user to specify a path that points to either a go.work file (in case of a project with workspaces), or a go.mod file (in case of a project without workspaces).

[chmeliik]

There's also a fairly significant bug caused by the current design: cachi2 doesn't list packages from workspace modules other than the one specified by the user - https://github.com/containerbuildsystem/cachi2/pull/553#discussion_r1654667805