[3.15] gh-129724: Intern string constants in the compiler, not per code object (GH-159193)

[miss-islington]

The compiler merges equal constants of a module through its constant
cache. intern_constants() then ran on each code object and rebuilt a
frozenset (or, in the free-threaded build, a slice) when one of its
strings was replaced by an already interned one, so a constant shared by
several functions was copied for some of them depending on which strings
happened to be interned in the process. The class body's qualname
constant and co_qualname had the same problem. marshal then wrote
different bytes for the same source.

Intern the eligible strings of the final constants of each code unit
after optimization and before the code object is created. Tuples are
updated in place; a frozenset or slice is rebuilt once and stored in the
constant cache so that later units get the same object. The same code
is used in both builds.

Which strings are interned does not change, except that identifier-like
strings in slice constants are now interned in the default build too.

TestConstantsIdentity compares the identity graph and the marshal
output of code compiled in differently prepared processes, including
names tuples shared with constants.
(cherry picked from commit 627eabf)

Co-authored-by: Gregory P. Smith 68491+gpshead@users.noreply.github.com

• Issue: Bytecode compilation output depends on order of files compiled #129724