When negotiating TLS 1.3, AWS-LC always prefer client ciphers order

### Problem:

When negotiating TLS <= 1.2, there is an option to prefer server ciphers order (`SSL_OP_CIPHER_SERVER_PREFERENCE`).

But when negotiating TLS1.3, a separate code path is used, and AWS-LC always prefer client ciphers order. Indeed, in `ssl_choose_tls13_cipher` (see https://github.com/aws/aws-lc/blob/main/ssl/s3_both.cc#L688), iteration is done on client ciphers, and first one being also present in server ciphers will be selected, regardless of `SSL_OP_CIPHER_SERVER_PREFERENCE` being set or not. There is also a mechanism to avoid AES ciphers if there is no hardware support for it, but it is not relevant here.

This makes AWS-LC's behavior not consistent, and one could expect that `SSL_OP_CIPHER_SERVER_PREFERENCE` is respected regardless of protocol version.

As an example, see here a user report here that illustrate the issue when using HAProxy: https://github.com/haproxy/haproxy/issues/3024.
The user there tests their setup using `testssl.sh` and gets the following result: `Has server cipher order? yes (OK) -- only for < TLS 1.3`

### Solution:

`SSL_OP_CIPHER_SERVER_PREFERENCE` should be used in ssl_choose_tls13_cipher to decide whether iteration is done on client or server cipher list, in order to prefer server ciphers if set.

### Requirements / Acceptance Criteria:

Negotiation should be consistent in both TLS 1.3 and TLS 1.2, and server ciphers should be preferred if `SSL_OP_CIPHER_SERVER_PREFERENCE` is set, also for TLS 1.3.

* **Testing:** How will this change be tested? Some test should be added, checking cipher selection preference for TLS 1.3.

Start by reading ssl_choose_tls13_cipher in ssl/s3_both.cc, especially how it iterates over client and server cipher lists and checks SSL_OP_CIPHER_SERVER_PREFERENCE. Add coverage for TLS 1.3 cipher selection, then verify that server ciphers are preferred when the option is set and that negotiation remains consistent with TLS 1.2.

Written by the indexing model from the issue text.