Inconsistency constructing settings & scan results paths

[deadmoose]

In the UI, there are two separate handlers deriving scan settings & results paths based on the scanroot when it changes:

• https://github.com/scanoss/scanoss.cc/blob/main/frontend/src/components/ScanDialog.tsx#L175-L179 - when the dialog is first opened
• https://github.com/scanoss/scanoss.cc/blob/main/frontend/src/components/ScanDialog.tsx#L78 - when the file selector is used

In addition to being two copies of the same string building, it's doing that without worrying about the platform-local path separators (e.g. on windows you get a path mixing forward & backslashes such as C:\foo\bar\baz/.scanoss/results.json)

From there, in the UI the output location is immutable, but users ARE able to update the settings file location.

When a scan is performed, the values are pulled from the UI elements & built into the string array passed to ScanStream, and then it calls SetScanRoot bridging over to go-land:

• https://github.com/scanoss/scanoss.cc/blob/main/frontend/src/components/ScanDialog.tsx#L117

In THAT, it does its own job of setting results & settings paths based on the scanroot. That DOES use golang's path/filepath, so they use proper path separators.

• https://github.com/scanoss/scanoss.cc/blob/main/internal/config/config.go#L157-L164

However, as mentioned above, the settings file location may have been modified in the UI, and this will stomp on it so it doesn't persist to the next time you open the scan dialog (although as mentioned above, opening the dialog ALSO stomps on whatever custom values may have been there)

This all leads to a series of closely entangled issues:

• There are 3 separate implementation of the logic deriving the results + settings paths based on scanroot which need to kept in sync
• The 2 javascript implementations fail to handle platform-native path separators
• Despite the UI being mutable for the settings file location, it's almost immutable because it's frequently stomped on
• The scan results path is theoretically mutable via a flag (--input) but effectively immutable because the UI always stomps on it before it's ever used

[deadmoose]

Oh, and the other-other closely related issue worth keeping in mind while digging into this:

Currently the ordering is:

1. Call ScanStream with args built based on values from the UI
2. Update the config object with the values from the UI

Upstream here, that's fine because ScanStream only cares about the string slice of flags to pass along to the python tool. I've got a forked scan implementation that does read things from the config object, so I've had to flip those two lines. (Which also demonstrates how ephemeral the UI's settings file field is)