feat(github): add devnet test release tracker issue template

[spencer-tb]

🗒️ Description

Adds a devnet test release tracker issue template , EL only. The aim of this tracker is to give us a process that signals to clients early on what is going in the next test release, and help us plan the next test releases more evenly across the team. I propose we start with something like this tracker template and update it in the future once we see what should be visualized and denoted more clearly.

Each test release must start with a devnet tracker, i.e for each <feat>-devnet@vX.Y.Z , even the small test version bumps. This tracker will be constantly updated, and used to prepare the test fixture devnet release notes.

If we followed this process today, we would have a tracker for bal-devnet@v7.3.0:
https://discord.com/channels/1359927674746835211/1386730600333054122/1507339893595050156,
and a tracker for glamsterdam-devnet@v5.0.0:
https://discord.com/channels/595666850260713488/1503770570829856898/1507344484352921712.

The trackers will be posted in the STEEL discord upon creation, and our website will have redirect links to the correct issue tracker, using both cc @danceratopz on how to do this:

• https://steel.ethereum.foundation/-devnet/vX.Y.Z
• https://steel.ethereum.foundation/-devnet/latest

As part of our future process we should always have a devnet N and devnet N+1 trackers open. This unblocks client teams, and helps them work ahead if they have spare bandwidth, opening up spec issues/questions earlier. In an ideal world we would have N+M trackers with a devnet plan for the entire fork lifecycle but N/N+1 is a good first start!

Open Question

• Testnets? Should they use the same tracker, testnets will use a consensus@vX.Y.Z release and be tagged from forks/amsterdam, not a feat-devnet@vX.Y.Z release tagged from a feat-devnet-X branch.

🔗 Related Issues or PRs

N/A.

✅ Checklist

• All: Ran fast static checks to avoid unnecessary CI fails, see also Code Standards and Enabling Pre-commit Checks:

  just static

• All: PR title adheres to the repo standard - it will be used as the squash commit message and should start type(scope):.
• All: Considered updating the online docs in the ./docs/ directory.
• All: Set appropriate labels for the changes (only maintainers can apply labels).

Cute Animal Picture

[marioevz]

I think this is a great starting point. I wrote a few comments.

[spencer-tb]

Addressed the comments but converting back to draft as I don't like the format now haha