fix: faster toString for integrity

[H4ad]

Performance before:

parsed.toString() x 1,595,186 ops/sec ±1.35% (90 runs sampled)
parsedStrict.toString() x 1,553,016 ops/sec ±1.82% (90 runs sampled)

After:

parsed.toString() x 8,128,007 ops/sec ±1.82% (90 runs sampled)
parsedStrict.toString() x 8,322,286 ops/sec ±1.30% (93 runs sampled)

benchmark.js

const Benchmark = require('benchmark')
const ssri = require('./lib/index');
const suite = new Benchmark.Suite;

const integrity = `sha512-WrLorGiX4iEWOOOaJSiCrmDIamA47exH+Bz7tVwIPb4sCU8w4iNqGCqYuspMMeU5pgz/sU7koP5u8W3RCUojGw== sha256-Qhx213Vjr6GRSEawEL0WTzlb00whAuXpngy5zxc8HYc=`;
const parsed = ssri.parse(integrity);
const parsedStrict = ssri.parse(integrity, { strict: true });

suite
.add('parsed.toString()', function () {
  parsed.toString()
})
.add('parsedStrict.toString()', function () {
  parsedStrict.toString()
})
.on('cycle', function(event) {
  console.log(String(event.target))
})
.run({ 'async': false });

When parsing is strict, I introduce a small break change because I know the possible hashes, so I call it directly.
Instead of the toString being stringified in the order in which the hashes were added, it will always be stringified in this order: sha512, sha384 and sha256.

If you think that is problematic, we can keep the loop, even if is a little bit slower.

References

Related to #71

[wraithgar]

npm run lintfix should shore up the linting errors (it usually fixes everything but line length warnings)

[wraithgar]

Reading the readme again we do not make any guarantees about the order that the algorithms will be in toString. The order doesn't matter to things like parse either so I think this can remain a patch release.