public fields are displayed just fine for now, and private fields are not enabled (see Bug 1562054)

I just noticed this bug! Bug 1650188 may be a dupe of this (though, that bug also includes point about the result computation system)

It would be great to do something similar to what Chrome is doing.
Matthew, do you have an idea of how much work there is on the platform to provide a way for DevTools to retrieve the private fields and their value?

So, the functionality is at least partially already extant.

From devtools perspective, I'm not sure what things look like, but from the JSAPI side, you're looking at a call to js::GetPropertyKeys, and you just need to add JSITER_PRIVATE to the flags to have it include private names in the list.

Getting values should just be a matter of calling GetOwnProperty with the private name JSID.

This patch makes use of the new getOwnPrivateProperties method on DebuggerObject
to include private properties in object grip preview.

We're also adding a PrivatePropertiesIterator actor (and associated front) that
will allow us to retrieve all the private properties (e.g. when expanding an
object in the ObjectInspector).

A xpcshell test is added to ensure we do return the expected properties.

This patch surface the private properties in Reps and in the ObjectInspector.
Tests cases are added to cover the basic behaviors we want to have in the
same version private fields are shipped in (90).

Depends on D114373

assertPreviews was hovering over a token and then checking the Redux store in
order to assert what should be in the popup. This can be a bit brittle and it's
probably safer to check what's rendered in the DOM, as it directly maps to what's
shown to the user.
Some unused or irrelevant test helpers are removed, and tests are updated accordingly.

Depends on D115702

https://hg.mozilla.org/mozilla-central/rev/f1b290559447
https://hg.mozilla.org/mozilla-central/rev/31e604725431
https://hg.mozilla.org/mozilla-central/rev/92356fb78f95