Move ERC1967 to Final (Last call deadline reached) (ethereum#5035)

* Make ERC1967 final as per the end of the last call period

* Make ERC1967 final as per the end of the (second) last call period

EIPS/eip-1967.md

@@ -4,8 +4,7 @@ title: Standard Proxy Storage Slots
 description: Standardise where proxies store the address of the logic contract they delegate to, as well as other proxy-specific information.
 author: Santiago Palladino (@spalladino), Francisco Giordano (@frangio)
 discussions-to: https://ethereum-magicians.org/t/eip-1967-standard-proxy-storage-slots/3185
-status: Last Call
-last-call-deadline: 2022-05-14
+status: Final
 type: Standards Track
 category: ERC
 created: 2019-04-24
@@ -94,7 +93,7 @@ The fact that proxy public functions are potentially exploitable makes it necess
 
 The main requirement for the storage slots chosen is that they must never be picked by the compiler to store any contract state variable. Otherwise, a logic contract could inadvertently overwrite this information on the proxy when writing to a variable of its own.
 
-Solidity maps variables to storage based on the order in which they were declared, after the contract inheritance chain is linearized: the first variable is assigned the first slot, and so on. The exception is values in dynamic arrays and mappings, which are stored in the hash of the concatenation of the key and the storage slot. The Solidity development team has confirmed that the storage layout is to be preserved among new versions: 
+Solidity maps variables to storage based on the order in which they were declared, after the contract inheritance chain is linearized: the first variable is assigned the first slot, and so on. The exception is values in dynamic arrays and mappings, which are stored in the hash of the concatenation of the key and the storage slot. The Solidity development team has confirmed that the storage layout is to be preserved among new versions:
 
 > The layout of state variables in storage is considered to be part of the external interface of Solidity due to the fact that storage pointers can be passed to libraries. This means that any change to the rules outlined in this section is considered a breaking change of the language and due to its critical nature should be considered very carefully before being executed. In the event of such a breaking change, we would want to release a compatibility mode in which the compiler would generate bytecode supporting the old layout.