Add support for equal preference group

[franklee26]

Description of changes:

This PR adds support for equal preference grouping for server side cipher preferences. This is done by adding two new dummy 'delimiter' cipher suites s2n_equal_preference_group_start and s2n_equal_preference_group_start. Ciphers sandwiched between the start and end cipher suites are grouped into an equal-preference; the client's cipher preference is the tie breaker. Otherwise, ciphers that are not sandwiched between the delimiters are not in an equal-preference group. For example, take the following cipher preference list:

static struct s2n_cipher_suite *example_cipher_preference[] = {
    &a,              
    &s2n_equal_preference_group_start,                             /* start group */
    &b,                                 
    &c,                                        
    &s2n_equal_preference_group_end,                              /* end group */
    &d,   
};

/* Equivalently expressed in BoringSSL's `mini-language`: [a, [b | c], d] */

An s2n-tls server with the above cipher preferences has cipher suite a as their most preferred cipher. Next, both b and c are tied as 2nd most preferred (the client's preference is the tie breaker) and d is the least preferred.

This means that if a client were to indicate his/her cipher preferences as [d, c, b, e] then the server would select cipher c. This is because s2n-tls will attempt to first negotiate cipher a, but because it is not offered by the client then the server moves down it's cipher preferences. In second most preferred are ciphers b and c. Because the client has indicated preference for c over b then the server selects c. The client and server will then agree on cipher c.

Because existing cipher preference list's do not have group delimiter ciphers, then the server cipher selection behaviour remains the same. In other words, this change does not impact existing security policies.

This PR replaces the current server cipher selection with new functions that supports equal preference grouping and includes their respective unit tests.

Call-outs:

• No new public security policies are added in this PR. This will be done in the next PR.
• No new documentation is added in this PR. Also will be done in next PR.
• The current parsing logic does not perform any validation on the cipher preferences. This means that if by a miracle a security policy with an invalid cipher preference were added then this could cause unexpected errors. For example, the following cipher suite preferences could cause errors: [&a, &end, &start, &b, &start, &end, &start, &c]. Will investigate adding simple parsing validation in the next PR.

Testing:

• New unit tests added to s2n_cipher_suite_match_test

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.