More careful impl of hiwire_bool, added test cases

[hoodmane]

For a jsproxy, bool(val) is defined as (val && (val.length === undefined || val.length)). This seems to encode the assumption that anything with a length field is some sort of container. However, there are many things that are not a container that have a length field. window.length is the number of elements in the window, typically zero, so it considers window to be falsey. Functions also have a length field which counts their arguments, zero argument javascript functions are currently falsey.

Also, this implementation doesn't know about Set or Map, empty javascript sets and maps are truthy. I replaced it with a smarter implementation.

I also replaced the == and != in hiwire_eq resp hiwire_neq with === and !==. On the code paths that use hiwire_eq and hiwire_neq, these do the same thing, but === and !== are less confusing.

There is one more != operator:
https://github.com/iodide-project/pyodide/blob/1cb32c304d3901a57e95226e6b528501047cff01/src/core/hiwire.c#L428

However, the one place that != operator is used is in JsProxy_IterNext:

  JsRef iddone = hiwire_get_member_string(idresult, "done");
  int done = hiwire_nonzero(iddone);
  hiwire_decref(iddone);

Here iddone is either true or false and false !== 0 is true but false != 0 is false. So if we corrected hiwire_nonzero to be sensible it would break JsProxy_IterNext.

[dalcde]

I must be missing something obvious; what is wrong with `!!val` ? When the object is a PyProxy?

[hoodmane]

They wanted empty containers to be falsey. !![] === true in javascript. Question is whether we are trying to be like javascript or like python in our answers.

[rth]

Thanks! Please add a changelog entry.

[hoodmane]

Thanks!