Improve the documentation for identity semantics of mutable and immutable types #122511

Current paragraph:

Types affect almost all aspects of object behavior. Even the importance of object identity is affected in some sense: for immutable types, operations that compute new values may actually return a reference to any existing object with the same type and value, while for mutable objects this is not allowed. E.g., after a = 1; b = 1, a and b may or may not refer to the same object with the value one, depending on the implementation, but after c = []; d = [], c and d are guaranteed to refer to two different, unique, newly created empty lists. (Note that c = d = [] assigns the same object to both c and d.)

Proposed changes:

Types affect almost all aspects of object behavior. Even the importance of
object identity is affected in some sense.

For immutable types such as :class:int or :class:str, operations that
compute new values may actually return a reference to any existing object
with the same type and value, e.g., after a = 1; b = 1, a and b may
or may not refer to the same object with the value one.

For mutable types such as :class:list or :class:dict, this is not allowed,
e.g., after c = []; d = [], c and d are guaranteed to refer to two
different, unique, newly created empty lists (note that e = f = [] assigns
the same object to both e and f).

cc @mdeiana @terryjreedy

Related: #122463

Linked PRs

• gh-122511: improve documentation for mutable/immutable types behaviours #122512
• [3.13] gh-122511: Improve documentation for object identity of mutable/immutable types (GH-122512) #122778
• [3.12] gh-122511: Improve documentation for object identity of mutable/immutable types (GH-122512) #122779