Create /final/ permalinks for final CAIPs

[bumblefudge]

I created this PR to make an extra /final/ path freezing a second copy (at a second path) of each CAIP at the time it goes final.

While I was in here, I updated what little is said about the "status" field and its values in CAIP-1, and updated contributing.md to be more explicit about all this for contributors. @ligi might want to check the CAIP-1 edits!

As for next steps, I keep wondering what this means for errata or post-final edits. I think the best solution would probably be to display links back and forth between the /final/ version and the "post-final" version that lives on in /CAIPs/ which would be the equivalent of a W3C "Editor's Draft" (a less-binding version with errata applied or displayed as a differential in-line, IETF style). If the editorial WG agrees, we can open a separate issue for that tweak.

Similarly, I wonder if having an ipfs://{cid} version of each final might also be good, just in case. Also worth its own issue if that's an idea worth playing with.

[bumblefudge]

For context see https://github.com/ethcatherders/EIPIP issue 320

[obstropolos]

@ligi - whenever you have some time can you take a look here / quick review?

[bumblefudge]

Since EIP link policy is actually just pointing to commit-specific versions of files in github view, and not jekyll, this is no longer urgent so I'm gonna switch it to Draft. I think I would rather replace Jekyll with a more elegant static site generator anyways (R.I.P. 11ty) down the road, which would not require the gymnastics of creating a final file in a separate directory... would rather a version-aware generator or something more like IETF Datatracker that presents rendered and raw versions of the docs. Leaving this in the backlog for now