Unit Tests for "dummy" EncryptedClientHello

### Problem:
Some TLS Clients (Browsers) are sending dummy EncryptedClientHello values ~(filled with a stream of `0xFF` bytes)~ to all TLS server endpoints they connect to so that ISP's and middleboxes can't just block all TLS ClientHellos that send an EncryptedClientHello extension.

### Need By Date:
None

### Solution:

s2n-tls server already correctly handles this case by ignoring unknown TLS extensions, but we should add an explicit unit test that ensures we don't regress on this behavior, and verifies that s2n-tls ignores invalid ECH extensions.

### Requirements / Acceptance Criteria:

What must a solution address in order to solve the problem? How do we know the solution is complete?

* **RFC links:** https://datatracker.ietf.org/doc/html/draft-ietf-tls-esni
* **Related Issues:** https://github.com/aws/s2n-tls/issues/4231
* **Will the Usage Guide or other documentation need to be updated?**
* **Testing:** How will this change be tested? Call out new integration tests, functional tests, or particularly interesting/important unit tests.
* **Will this change trigger SAW changes?** No
* **Should this change be fuzz tested?** No

### Out of scope:

Supporting EncryptedClientHello extension

[//]: # (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/ )

No file or existing test is named. Start by locating the s2n-tls server-side TLS extension unit tests and run the relevant test suite to understand how unknown extensions are handled. Done means an invalid dummy EncryptedClientHello extension is explicitly covered and the server continues to ignore it.

Written by the indexing model from the issue text.