chore(binding-opcua): upgrade node-opcua family to 2.179.0

[erossignon]

Bumps all node-opcua-* packages to 2.179.0 (node-opcua-crypto to 5.9.0).

These packages release together and must be upgraded as a set, so per-package dependabot PRs can't build. Replaces #1549 and #1551 — both can be closed.

Needed by crypto 5: x509 identity uses clientCertificateManager.getPrivateKey(), and skipLibCheck in the examples tsconfig for the transitive asn1-schema ESM typings.

npm run ncu:opcua is the upgrade procedure, now documented in the binding README.

All 73 binding-opcua tests pass.

[danielpeintner]

This setting is a bit unfortunate, but since it is for examples only, I am fine with it.

[danielpeintner]

@relu91 do you think it is fine as well?

[erossignon]

Agreed it's unfortunate. Some context, as I maintain node-opcua.

Removing skipLibCheck produces these errors, and only these:

node_modules/@peculiar/asn1-schema/build/types/convert.d.ts(1,39): error TS1479:
The current file is a CommonJS module whose imports will produce 'require' calls;
however, the referenced file is an ECMAScript module and cannot be imported with
'require'.
... same for parser.d.ts, types/bit_string.d.ts, types/octet_string.d.ts

node-opcua-crypto handles OPC UA certificate management -- X.509 parsing and validation, PKCS#8/#12 private keys, CMS signatures -- and relies on the @peculiar ASN.1/X.509 stack for it (asn1-x509, asn1-pkcs8, asn1-cms, x509, webcrypto). Those all sit on @peculiar/asn1-schema, which in v2.9.4 added a dependency on @peculiar/utils. That is where the new error comes from.

The diagnostic is spurious. @peculiar/utils is dual-published and its exports map has a working require condition, but it sets "type": "module" and points a single .d.ts at both conditions with no .d.cts. Under moduleResolution: Node16 TypeScript therefore reads the declarations as ESM and raises TS1479, even though the CJS path resolves fine at runtime. All four errors are inside node_modules; none are in our source.

binding-opcua has carried skipLibCheck: true since #1335 (Feb 2025) for the same dependency chain. Since skipLibCheck is per-project and does not propagate to consumers, examples needs its own entry once it imports the binding.

I looked for a narrower fix within tsconfig and could not find one. A paths override remapping @peculiar/utils to a local .d.cts shim just relocates the same TS1479 into the shim, because TypeScript derives a declaration's module format from the "type" field of its containing package.json rather than from the resolved path.

The proper fix belongs upstream, so I have raised PeculiarVentures/pvtsutils#23 proposing per-condition types with a generated .d.cts declaration set, and offered to send the PR. This is the remaining half of PeculiarVentures/asn1-schema#130, which the same maintainer fixed promptly for classic moduleResolution: "node". Once that ships, both skipLibCheck entries can come out.