Since this is always called from DTLS code it is safe to assume the header
length should be the DTLS value. This avoids the need to check the version
number and should work with any version of DTLS (not just 1.0).

Extend DTLS method creation macros to support version numbers and encryption
methods. Update existing code.

Some TLS extensions were disabled for DTLS. Possibly because they caused
problems with the old duplicated code. Enable them again.

Based on suggestions from Shay Gueron and Vlad Krasnov.
PR: 3021

The only standard compression method is stateful and is incompatible with
DTLS.

PR: 3002

Use the enc_flags field to determine whether we should use explicit IV,
signature algorithms or SHA256 default PRF instead of hard coding which
versions support each requirement.

Revise DTLS code. There was a *lot* of code duplication in the
DTLS code that generates records. This makes it harder to maintain and
sometimes a TLS update is omitted by accident from the DTLS code.

Specifically almost all of the record generation functions have code like
this:

some_pointer = buffer + HANDSHAKE_HEADER_LENGTH;
... Record creation stuff ...
set_handshake_header(ssl, SSL_MT_SOMETHING, message_len);

...

write_handshake_message(ssl);

Where the "Record creation stuff" is identical between SSL/TLS and DTLS or
in some cases has very minor differences.

By adding a few fields to SSL3_ENC to include the header length, some flags
and function pointers for handshake header setting and handshake writing the
code can cope with both cases.

Note: although this passes "make test" and some simple DTLS tests there may
be some minor differences in the DTLS code that have to be accounted for.

If an ASN1_INTEGER structure is allocated but not explicitly set encode
it as zero: don't generate an invalid zero length INTEGER.
(cherry picked from commit 1643edc63c3e15b6db5a15a728bc288f2cc2bbc7)

(cherry picked from commit 1546fb780bc11556a18d70c5fb29af4a9d5beaff)

Add DTLS record header parsing, different client hello format and add
HelloVerifyRequest message type.

Add code to d1_pkt.c to send message headers to the message callback.

Add code to support GCM an CCM modes in evp_test. On encrypt this
will compare the expected ciphertext and tag. On decrypt it will
compare the expected plaintext: tag comparison is done internally.

Add a simple CCM test case and convert all tests from crypto/modes/gcm128.c

Thanks to Shay Gueron & Vlad Krasnov for report.

Simple example of CCM code use: translated from the FIPS self tests.

Conflicts:
	util/mk1mf.pl

Make assembly language handling conditional on the "copy" platform
as Windows does its own thing here.

PR: 3005