Propose sequencing header

# Rationale

Ethereum fragmentation via L2 sequencing silos has arguably been a primary cause of ETH’s divergence from BTC since the significant rise of L2s in the last two years. This is because the value of transactions at the L2 layer has devalued the value of the L1; in other words, we currently risk the market taking the L1 layer for granted, which would create an existential threat to the proof of stake consensus system. Thus, this proposal suggests that new ERCs should be required to state whether and how they align with the goal of Shared Sequencing/Universal Synchronous Composability. Such mandatory statements during the ERC proposal process can assist both editors and Core Devs with the review of new ERCs in relation to the Ethereum roadmap.

# Summary of changes:
- Add fragmentation status metadata and a description of its use to the EIP Header Preamble.
- Add review responsibility to EIP editor to ensure fragmentation status metadata is present.

# Notes:
- The only ERC of `type: Meta` is currently EIP-1. EIPs have made more heavy use of Meta documents than ERCs, with 36 Meta EIPs so far. Therefore, this change is proposed to EIP-1 instead of introducing a new Meta ERC.
- The use of `other` as a possible value for the `sequencing` header is considered suboptimal, but was included to future-proof the proposal in the case that other sequencing solutions beyond `based` and `shared` become available. Alternatives to this approach would be very welcome.

# Dependencies:
- If accepted, this change would require an update to https://github.com/ethereum/EIPs/blob/master/eip-template.md or a fork of that template to the ERC repository.
- If accepted, this change would require either the same change to be made to the version of EIP-1 in the EIPs repository, or the creation of a fork of EIP-1 in the ERC repository.

ERCS/eip-1.md

@@ -142,6 +142,8 @@ Each EIP must begin with an [RFC 822](https://www.ietf.org/rfc/rfc822.txt) style
 
 `withdrawal-reason`: *A sentence explaining why the EIP was withdrawn.* (Optional field, only needed when status is `Withdrawn`)
 
+`sequencing`: One of `based`, `shared`, `other` or `N/A`.
+
 Headers that permit lists must separate elements with commas.
 
 Headers requiring dates will always do so in the format of ISO 8601 (yyyy-mm-dd).
@@ -192,6 +194,14 @@ EIPs may have a `requires` header, indicating the EIP numbers that this EIP depe
 
 A `requires` dependency is created when the current EIP cannot be understood or implemented without a concept or technical element from another EIP. Merely mentioning another EIP does not necessarily create such a dependency.
 
+### `sequencing` header
+
+The `sequencing` header specifies whether an ERC relates to `based` sequencing, non-based `shared` sequencing, `other` forms of sequencing, or does not invovle sequencing at all (which is indicated by the use of `N/A`).
+
+EIPs MUST include a `sequencing` header if and only if the `category` is `ERC` and MUST NOT include one otherwise.
+
+For example, those applications using Ethereum mainnet's validators to sequence transactions would be noted as `based`. Those using [EIP-7727](./eip-7727.md) style sequencing would be considered `shared` because they may not choose to sequence transactions via the L1 validators.
+
 ## Linking to External Resources
 
 Other than the specific exceptions listed below, links to external resources **SHOULD NOT** be included. External resources may disappear, move, or change unexpectedly.
@@ -458,6 +468,7 @@ For each new EIP that comes in, an editor does the following:
 - Read the EIP to check if it is ready: sound and complete. The ideas must make technical sense, even if they don't seem likely to get to final status.
 - The title should accurately describe the content.
 - Check the EIP for language (spelling, grammar, sentence structure, etc.), markup (GitHub flavored Markdown), code style
+- Check the EIP for required headers.
 
 If the EIP isn't ready, the editor will send it back to the author for revision, with specific instructions.