Merge tests and fixes from stale PRs

[mielvds]

This PR attempts to integrate tests and fix from other PRs. Some of them are very old and are not mergeable anymore. However, most of these issues still persist and to not let this work go to waste, they are ported here:

Includes tests from or for issues:

• It is not always relevant to silently ignore unrecognized properties #50
• IRI expansion with missing @base does not conform to RFC 3986 #187
• Nested "@id" elements are not processed correctly in framing #149
• Fixed bugs in embed and remote frame context handling. #31
• Dates from schema.org are not compacted correctly. #59
• String xsd:double value crash toRdf() #202

Includes fix from or for:

• Proposed fix for issue #50 #51
• IRI expansion with missing @base does not conform to RFC 3986 #187
• Nested "@id" elements are not processed correctly in framing #149
• Fixed bugs in embed and remote frame context handling. #31
• Always try to add a default @type and @language #60 --> introduces regressions, so no included
• String xsd:double value crash toRdf() #202

[davidlehn]

General:

• I'm not sure this was the best approach to handle old issues and PRs. It's now very difficult to review, and difficult to handle one piece at a time.
• I don't think old issues should be closed until the issue is actually fixed, or at least merged into main.

Dropped "keys" / logging:

• The issue addressed by the on_key_dropped callback patch likely needs to be more involved. That was the path jsonld.js had to start. It then moved over to "safe mode" to handle that and many other situations that could cause problems when signing canonized output.
• If I had gotten to implementing a pyld "safe mode", it would likely have taken the simple path of throwing errors aligned with the js ones in all the needed places. More flexibility may only be needed for developer tools, which could be future work.
• Not sure what to suggest should be done here. This patch only handles one situation of many needed for a full "safe mode". An important one though.
• Is debug logging is the best default? Why not a no-op? The spec does allow dropped properties so arguably that's not something that needs debugging. If dropped properties are always an error is up for debate.
• On naming, I think "property" might be better than "key"? It aligns more with the spec. For the situation here, I think the js code is using a "invalid property" event / error code. But I understand the desire to match API naming with native data structures.