doc: deprecate type coercion for dns.lookup options

[aduh95]

The plan is to replace this check:

node/lib/internal/dns/promises.js

Lines 115 to 117 in d8797f5

	if(typeofoptions.verbatim==='boolean'){
	verbatim=options.verbatim===true;
	}

with a more robust validateBoolean check – and similar for other dns.lookup options.

[aduh95]

@nodejs/tsc if #37931 lands, the type coercion on the verbatim option could be a bit surprising as before any falsy value were interpreted as false – because that's still the default value. If the default changes, a falsy value that is not false will be interpreted as true – which could be a bit surprising.

Other dns.lookup options have the behavior, which could be problematic as well. E.g., dns.lookup('localhost', { family: 'ipv4' }), the family value here is simply ignored and is silently converted to 0 – which again, should cause issues if/when verbatim default value changes, as localhost will point to ::1 instead of 127.0.0.1.
My suggestion is to apply the same logic as we do in other part of the code base, which is to enforce types for dns.lookup options. I'm not sure if this kind of change deserve to go through a deprecation cycle, or if it can simply land as a semver-major.

For reference, here's the current logic:

node/lib/dns.js

Lines 115 to 120 in fa1a842

	hints=options.hints>>>0;
	family=options.family>>>0;
	all=options.all===true;
	if(typeofoptions.verbatim==='boolean'){
	verbatim=options.verbatim===true;
	}

[mcollina]

lgtm

[jasnell]

I'm landing this now, but in general deprecation PRs should leave the code number unassigned (e.g. use DEP0XXX) so that the code can be assigned when it is landed.

[jasnell]

Landed in fae352a...f41893e