Feature: Throw TypeErrors in serialize/parse with .code

[mao-sz]

As requested in #162 as a non-breaking change prior to a change of error messages for a future major release, standard Node error codes have been added to each of the parse and serialize functions' TypeError throws.

This should allow for a period of migrating for library users to error-handling via the .code error property, as opposed to the sole .message property, before they change (potentially breaking).

This PR

• Amends existing tests for parse and serialize to test for the correct error message and error code.
  • The above requires a shared helper function extracted to a separate file compare-error.js
• Adds a serialize sameSite test for non-string/true argument values.
• Adds .code properties with standard Node error codes to each error throw in both the parse and serialize functions.

[mao-sz]

Looks like asserting throws with a POJO was breaking backwards compatibility with the action runs. This change should hopefully be backwards compatible with the versions now.

[wesleytodd]

These CI issues are not related. In general this is great, but I think we should probably clean up the inconsistencies in formatting and also there are a few nits for after we get the CI passing.

[mao-sz]

Could I get some guidance on exactly what needs fixing here for the action runs? I'm a little confused as to why some tests that passed last run now suddenly fail after only changing the indentation for one of the files (which understandably was causing some of the later Node version tests to fail)
As far as I'm concerned, the original issue regarding the test object/callback has been resolved, as has the indentation and on my end, I remember Node v0.10 and v0.12 passing respectively.

[wesleytodd]

Could I get some guidance on exactly what needs fixing here for the action runs?

Ah, sorry yeah I should have been more clear. I don't think you need to fix this in this PR. I think we have been considering just dropping the coveralls stuff, but it is unclear what we want bigger picture. I don't want to block landing things on this kind of unrelated stuff, so what I was thinking is I would run these tests locally once to check, but I dont see anything which should break so I hope we could just skip the check and force re-run each test run since it got past that part.

[jonchurch]

allocating an error object when it's not needed incurs a small performance hit, due to the stack trace generation. The bigger the stack when this is generated, the bigger the hit. From microseconds to possibly miliseconds. Thats an edgecase, in the real world, but is still possible.

This is one of those instances where following Dont Repeat Yourself isn't worth the perf cost. We save a tiny amount of repetition, but at a performance cost.

[mao-sz]

Just want to clarify what the desired way forward would be.
I can update this PR with the error codes e.g.

// src/index.ts:250
if (!cookieNameRegExp.test(name)) {
  const nameError = new TypeError(`argument name is invalid: ${name}`);
  nameError.code = 'ERR_INVALID_ARG_VALUE';
  throw nameError;
}

Though since we're now using TS, I'd need to handle .code not being a property on the TypeError interface. How would you like me to proceed with that?

Also perfectly happy to have this PR superceded by #208, that's not a problem by any means (might even be preferable - very limited bandwidth currently so if this can be resolved more efficiently in that PR then that'd be wonderful).