feat: Add sri-history file and update process

[WilcoFiers]

Since axe-core is injected into many many web pages, it is very important that we’re able to check the integrity of the file we’re injecting. Keeping the SRI of all previously published versions around makes this much easier.

https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity

[marcysutton]

When I ran it my hashes changed for aXe-2.3.1, is that because there are changes on the develop branch but the version is still at 2.3.1?

[WilcoFiers]

Yeah, because this branched from dev, which has changes that aren't in 2.3.1. If you replace your axe.js file with the 2.3.1 release it'll match.

[marcysutton]

We need docs for this, since it isn't immediately clear when we should be running this command. It already impacted our latest releases of aXe-core.

[WilcoFiers]

@marcysutton Was it because we're not using npm version to bump the version? This PR should warn you before publishing with the wrong SRI. Did that not happen?

[marcysutton]

npm version doesn't update all the necessary files, and I haven't been using it. So yeah, that's probably the problem. We need to document this as part of our Build/Release process guidelines.

[WilcoFiers]

I can add a comment to the build file explaining it further. We shouldn't be doing this stuff manually anyway. We'll have Attest-master ready before the next release, so we'll automate this step. But yeah, not using npm version is probably where this went wrong than. Is that because of the changelog thing?

[marcysutton]

No, it's because I moved to npm run release, which doesn't use npm version and thus trigger sri-history. There are also 3 files that have to get bumped: package.json, bower.json and axe.d.ts, and npm version doesn't do it.