Formalizing requirements for specification changes.

After some more discussion at TPAC
<https://github.com/w3c/webappsec/blob/main/meetings/2025/2025-11-TPAC-minutes.md#admin-path-to-cr-maintenance-guardrails>,
I think we landed on general agreement in the room that it would be
reasonable to formalize requirements for specifications we think have moved
beyond incubation into a more "living" model, and also that leaning heavily
on WHATWG's well-proven templates was probably a good idea.

To that end, I put
https://github.com/mikewest/webappsec-templates/tree/main together
as a demonstration of a proposal for us to add to specs' repositories. It
does ~3 things:

   1.

   Creates a template for pull requests that asks for signals from browser
   engines, web platform tests, bugs to be filed against implementers, and a
   bug to be filed against MDN.
   2.

   Creates two issue templates: one for "issues", another for "features".
   This division seems quite helpful for WHATWG specs, and I think it's
   reasonable to push our specs in the same direction.
   3.

   Additions to our CONTRIBUTING.md that make those requirements clear.

Based on our experience with Subresource Integrity, I'd suggest that we
merge these templates into most* of our specs.

WDYT? https://github.com/w3c/webappsec/issues/688 would be a fantastic
place to weigh in.

*DBSC is the only one that seems to me to still be in enough flux that it
might benefit from a lower bar, but I'd ask that specification's editors to
weigh in on that).
-mike