added multiple signatures support

Hello,

it seems that Google Calendar invitation messages are signed by Google with 2 DKIM-Signatures...

>From: XXX YYY <xxxyyy@gmail.com>
>
>DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
>        d=google.com; s=20120113;
>
>DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
>        d=gmail.com; s=20120113;

... and that dkim_verifier (1.2.1) marks them as invalid because it only uses the google.com signature:

>Invalid (Wrong signer (should be gmail.com))

RFC6376 says...

>Verifiers SHOULD continue to check signatures until a signature
>successfully verifies to the satisfaction of the Verifier
>...
>6.  Verifier Actions
>...
>6.1.  Extract Signatures from the Message
>...
>For each signature to be validated, the following steps should be performed
>...
>6.1.3.  Compute the Verification
>...
>Should the algorithm reach this point, the verification has succeeded, and DKIM reports SUCCESS for this signature.

So I tried to add multiple signatures support to the addon in my pull.

I added an input parameter to most of the support functions (`computeBodyHash`, `computeHeaderHashInput`, `verifySignaturePart1`, `verifySignaturePart2`) and made `verifyBegin` calling a brand new function (`processSignatures`) instead of `verifySignaturePart1`.
The new function loops on the dkim-signature headers; for each signature tests if it matches and, if so, adds it to a local array (`verifiedSignatures`). Then, for each header in `verifiedSignatures`, it performs public key signature validation.
Of course errors logging, exceptions handling and Tasks management can be improved a lot!
I edited the 1.2.1 code, then merged changes in the last version of the file I found here on GitHub: I hope I have not made a mess!
I'll try using the modified version of the addon to debug it.
Later the are calling `pop()` on `headerFieldArray`. Either the algorithm needs to be changed so `pop()` is no longer used or we need to operate on a copy of `msg.headerFields`. Otherwise this produces something incorrect for the next signature because `msg.headerFields` no longer contains all headers.