fix(node/assert): throw on deepStrictEqual({}, Object.create(null))

[edilson258]

assert.deepStrictEqual now differentiates {} from Object.create(null)

This PR updates the object comparison logic to throw when comparing a plain object ({}) with an object created via Object.create(null), matching Node.js behavior.

Closes #27565

[edilson258]

There are some tests failing because they expect the old behavior where deepStrictEqual({}, Object.create(null)) is true, like:

deno/tests/node_compat/test/parallel/test-sqlite-transactions.js

Lines 32 to 43 in ff078dc

	t.assert.deepStrictEqual(
	db.prepare('BEGIN').run(),
	{ changes: 0, lastInsertRowid: 0 },
	);
	t.assert.deepStrictEqual(
	db.prepare('INSERT INTO data (key) VALUES (100)').run(),
	{ changes: 1, lastInsertRowid: 100 },
	);
	t.assert.deepStrictEqual(
	db.prepare('COMMIT').run(),
	{ changes: 1, lastInsertRowid: 100 },
	);

All the above assertions now fails because db.prepare('BEGIN').run() returns an object whose prototype is null __proto__: null, whereas the expected object { changes: 0, lastInsertRowid: 0 } has the default Object.prototype. Since assert.deepStrictEqual NOW checks both property values and the prototype chain, the difference in prototypes causes the assertion to fail.

I think that setting __proto__: null in the expected object is the best solution because it ensures that the object has no prototype and is an approach that is already being used in similar cases, like:

deno/tests/node_compat/test/parallel/test-sqlite-transactions.js

Lines 44 to 47 in ff078dc

	t.assert.deepStrictEqual(
	db.prepare('SELECT * FROM data').all(),
	[{ __proto__: null, key: 100 }],
	);

There are lots of assertions in the code base that rely on that old behavior, this patch will touch lots of files in the source tree.

Is that proposed change acceptable?

@kt3k
@bartlomieju

[kt3k]

@edilson258 Thanks for the PR. The maintainers will work on the fixes for the existing test cases (they should be passing as is). Please wait for a moment.