Allow for limiting client hello size

### Problem:

TLS RFCs do not limit the size of a client hello, and thus s2n-tls does not have any limitations on how large a client hello may be. This allows for clients to send excessively large client hellos without an easy way to prevent that.

### Solution:

Add an API to enable configuration of a maximum client hello size, or determine a reasonable maximum client hello size and add an API that turns on enforcement of that size

* **Does this change what S2N sends over the wire?** No
* **Does this change any public APIs?** No (new config api)
* **Which versions of TLS will this impact?** all

### Requirements / Acceptance Criteria:

The new API allows for excessively large client hellos to be rejected

* **RFC links:** Links to relevant RFC(s)
* **Related Issues:** Link any relevant issues
* **Will the Usage Guide or other documentation need to be updated?**
* **Testing:** Unit tests
* **Will this change trigger SAW changes?** Maybe
* **Should this change be fuzz tested?** Will it handle untrusted input? Create a separate issue to track the fuzzing work.

### Out of scope:

Is there anything the solution will intentionally NOT address?

[//]: # (NOTE: If you believe this might be a security issue, please email aws-security@amazon.com instead of creating a GitHub issue. For more details, see the AWS Vulnerability Reporting Guide: https://aws.amazon.com/security/vulnerability-reporting/ )

Start by locating the client hello parsing path and the configuration API definitions in s2n-tls. Review the relevant unit-test structure, then define and test rejection of client hellos above the configured or selected maximum across all TLS versions. Done means the new API enforces the limit and unit tests cover the behavior.

Written by the indexing model from the issue text.