fix: support scanoss bundling

[sdirix]

What it does

scanoss depends on node-fetch <3. node-fetch in that version fails their instance checks, as it relies on constructor/class names which are removed by the backend bundling.

Adjusts the generated webpack configuration to keep the class name for AbortSignal as this is the name checked in node-fetch.

fixes #14648

How to test

yarn && yarn browser build:production

Without the adjusted webpack generation, scanoss will fail

Follow-ups

As an alternative we could set a resolution to node-fetch >3, however

• this change will not be picked up by adopters automatically
• it produces warnings whenever scanoss is used as node-fetch in that version deprecated support for form-data dependency which is used by scanoss.

So to get rid of this workaround we need to either

• encourage / support scanoss to migrate to node-fetch v3 and replace form-data usage, AND/OR
• encourage / support node-fetch to backport their improved checks to version v2

Note that the ai-openai and ai-anthropic also have a dependency to node-fetch v2, however during regular use we don't seem to hit the problematic code paths in there, at least I was not able to trigger them.

Breaking changes

• This PR introduces breaking changes and requires careful review. If yes, the breaking changes section in the changelog has been updated.

Review checklist

• As an author, I have thoroughly tested my changes and carefully followed the review guidelines

Reminder for reviewers

• As a reviewer, I agree to behave in accordance with the review guidelines

[tsmaeder]

@sdirix when I press the "scanoss" button in the chat view on a production build of the electron version, nothing happens and I get the following exception:

rpc-message-encoder.ts:184 Uncaught (in promise) TypeError: Cannot read properties of undefined (reading '0')
    at s.doScanContent (/C:/Users/thomas/cod…nd\main.js:1:435940)
    at async h.onRequest (/C:/Users/thomas/cod…kend\306.js:1:52201)
    at async c.handleRequest (/C:/Users/thomas/cod…kend\306.js:1:47057)
deserialize	@	rpc-message-encoder.ts:184
D	@	unpack.js:424
i	@	unpack.js:522
X	@	unpack.js:994
D	@	unpack.js:418
x	@	unpack.js:197
unpack	@	unpack.js:104
decode	@	unpack.js:176
decode	@	rpc-message-encoder.ts:163
parse	@	rpc-message-encoder.ts:167
(anonymous)	@	rpc-protocol.ts:88
(anonymous)	@	event.ts:176
invoke	@	event.ts:184
fire	@	event.ts:327
handleData	@	channel.ts:255
handleMessage	@	channel.ts:209
(anonymous)	@	channel.ts:167
(anonymous)	@	event.ts:176
invoke	@	event.ts:184
fire	@	event.ts:327
t	@	ws-connection-source.ts:156
n.emit	@	index.js:136
emitEvent	@	socket.js:559
onevent	@	socket.js:546
onpacket	@	socket.js:514
n.emit	@	index.js:136
(anonymous)	@	manager.js:237
await in (anonymous) (async)		
Be	@	react-dom.production.min.js:54
ze	@	react-dom.production.min.js:54
(anonymous)	@	react-dom.production.min.js:55
Nn	@	react-dom.production.min.js:105
Fn	@	react-dom.production.min.js:106
(anonymous)	@	react-dom.production.min.js:117
cc	@	react-dom.production.min.js:273
Oe	@	react-dom.production.min.js:52
Hn	@	react-dom.production.min.js:109
qt	@	react-dom.production.min.js:74
Gt	@	react-dom.production.min.js:73

[tsmaeder]

This seems to have no untoward effects on Theia in the production build. Can't test it fixes the ScanOSS problem until we have the other Windows fix merged, but at least it's no worse (the feature does not work anyway)

[sdirix]

The error mentioned was an issue only appearing on Windows. It was fixed here: #14653