gh-78274: Produce consistent output from marshal.dumps().

[ericsnowcurrently]

The result on debug vs. non-debug builds were slightly different. This PR fixes that by making an additional pass over the object to ensure "refs" are used more than once. Consequently, marshal.dumps() is substantially slower. To mitigate this, I've added to it a keyword-only arg, "stable", to allow folks to opt out.

FYI, I discovered gh-8293 after the fact, which turns out to have a lot of similarities to this PR.

• Issue: Reproducible pyc: FLAG_REF is not stable. #78274

[ericsnowcurrently]

@gvanrossum, is something like this what you had in mind?

[gvanrossum]

Probably, but I'm probably not going to be able to review it before Monday.

[ericsnowcurrently]

It would probably make sense to default to False for now, so users would effectively opt-in to the performance penalty. (The same goes for marshal.dump().)

[ericsnowcurrently]

As I noted in [bpo-34093](https://bugs.python.org/issue34093#msg402244), we could take a different approach to get the same stable output without having to call w_object() twice. However, this PR would probably be worth landing in the meantime.

[ericsnowcurrently]

This PR should probably also add a flag to determine if the import machinery would use marshal.dumps(code, stable=True). The same goes for the compileall module.

[github-actions]

This PR is stale because it has been open for 30 days with no activity.

[gvanrossum]

Maybe just close this? We no longer require marshal output to be stable for the freezing project, because we don't commit the files to git any more.

[methane]

We need to this to support "reproducible build" in downstream.

[iritkatriel]

This has merge conflicts now.

[bedevere-bot]

When you're done making the requested changes, leave the comment: I have made the requested changes; please review again.

[encukou]

Closing; see discussion in the issue.