fix: prevent print crash on bad deviceName

[codebytere]

Description of Change

On Windows and macOS, Chromium's printing code will crash if a deviceName is provided, but is invalid on the network, i.e does not correspond to a printer that the caller machine is aware of. This bug has been present for a long time, but after playing around a bit I've determined that it's possible to catch faulty deviceNames by pulling out some of the printer validation code from Chromium. This PR adds that check for Windows and macOS as well as tests for the same.

Tested with:

win.webContents.on('did-finish-load', () => {
   win.webContents.print({deviceName: 'bad-printer-name'}, (success, reason) => {
      console.log(`printing ${success ? 'did' : 'did not'} succeed: ${reason}`)
   })
})

cc @ckerr @zcbenz

Checklist

• PR description included and stakeholders cc'd
• npm test passes
• tests are changed or added
• relevant documentation is changed or added
• PR title follows semantic commit guidelines
• PR release notes describe the change in a way relevant to app developers, and are capitalized, punctuated, and past tense.

Release Notes

Notes: Fixed a potential crash on faulty deviceNames in webContents.print().

[deepak1556]

LGTM

[release-clerk]

Release Notes Persisted

Fixed a potential crash on faulty deviceNames in webContents.print().

[trop]

I was unable to backport this PR to "7-1-x" cleanly;
you will need to perform this backport manually.

[trop]

I was unable to backport this PR to "6-1-x" cleanly;
you will need to perform this backport manually.

[trop]

I have automatically backported this PR to "8-x-y", please check out #21982

[trop]

@codebytere has manually backported this PR to "7-1-x", please check out #22012