Per request sign algorithm (A part of issue #6)

[futatuki]

This extends KeyTable value fields as the issue comment #6 (comment) said.

With an extended KeyTable and lua script, I could confirm that the milter can both rsa-sha256 and ed25519-sha256 signature.

(Edit)
Now, this PR depends on PR #207 for conversion table for dkim_alg_t and dkim_canon_t (but not including those commits).

[futatuki]

I didn't care opendkim-testkey, so I'll update it later.

[futatuki]

I didn't care opendkim-testkey, so I'll update it later.

Done. However library function dkim_test_key() does not support ed25519 keys, so opendkim-testkey still reports "keys do not match" at ed25519 key entry.

[futatuki]

As commit message of commit 2fb3b18 is wrong, rebase latest 2 commit.

[futatuki]

As commit message of commit 2fb3b18 is wrong, rebase latest 2 commit.

Done.

[futatuki]

I separated lookup functions and tables from opendkim/opendkim.c into opendkim/opendkim-const.c because opendkim/opendkim-testkey.c uses conversion from sign algorithm string to sign algorithm internal code.

However I found it has been provided in libopendkim/dkim-tables.h, so I'll remove last 2 commit and I'll use dkim_name_to_code in opendkim/opendkim-testkey.c.

I think lookups for dkimf_canon and dkimf_sign in opendkim/opendkim.c should also use dkim_name_to_code or dkim_code_to_name with canonicalizations table and algorithms, but it is another issue.

[futatuki]

It turned out that all nametable s which should be used with dkim_code_to_name() or dkim_name_to_code() are all not exposed outside of the library because of their name, while the functions are exposed.

I believe those nametables are worth exposed. Also, there is no bad side effect if names of the tables are renamed by adding prefix 'dkim_', because all macros in the tables are already exposed.

[futatuki]

Now, it uses lookup table for dkim_alg_t and dkim_canon_t in libopendkim (by using PR #207).