fix: yarn.lock for frontend plugins

[gashcrumb]

This change updates the CLI's frontend script to create a yarn.lock based on the exported plugin package in a similar fashion to backend plugins, with the difference being the resulting node_modules folder is removed afterwards. This makes the exported plugin package for frontend plugins more consistent with backend plugins and allows another means for security scanners to inspect the plugin's dependencies.

Issue: https://issues.redhat.com/browse/RHIDP-11050

[github-advanced-security]

This pull request sets up GitHub code scanning for this repository. Once the scans have completed and the checks have passed, the analysis results for this pull request branch will appear on this overview. Once you merge this pull request, the 'Security' tab will show more code scanning analysis results (for example, for the default branch). Depending on your configuration and choice of analysis tool, future pull requests will be annotated with code scanning analysis results. For more information about GitHub code scanning, check out the documentation.

[nickboldt]

had a chat today with Kim and Rogue today to discuss how to move forward and the TL;DR is for the next 6mo:

• for now the only viable workaround is to include a filtered yarn.lock in the front end oci artifacts; we don't want to ALSO push the node_modules folder into the oci artifacts for the front end (performance degradation)

[sonarqubecloud]

Quality Gate passed

Issues
5 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[gashcrumb]

So on the remaining sonarqube complaints:

• Refactor this function to reduce its Cognitive Complexity from 49 to the 15 allowed. - this is for customizeForDynamicUse which I moved to a common location as it's used by both the frontend and backend export. I'm not keen on refactoring this now tbh
• The empty object is useless - well, it's not because in both cases it guards against trying to use the spread operator on potentially undefined
• Extract this nested ternery operation into an independent statement - tbh, I think the solution winds up being more complicated. I've also held off also making this functionality shared between the backend and frontend exports at least for now because the use case is different for each.