der: replace O(n^2) SetOf sort with O(n log n) sort

[arpitjain099]

Fixes #2319

Problem

der_sort() in der/src/asn1/set_of.rs is a hand-rolled insertion sort that runs on every SetOfVec / heapless SetOf decode in DER mode. It is O(n^2), and reverse-sorted input forces n(n-1)/2 comparisons and swaps. A crafted reverse-sorted SET OF (about 18k elements in 246 KB) makes a single SetOfVec::decode_value take roughly 11 seconds, a denial-of-service vector.

This is reachable from any SetOfVec<T> decoded from untrusted DER, including RelativeDistinguishedName in x509-cert (Certificate::from_der) and DigestAlgorithmIdentifiers / CertificateSet / SignerInfos in cms.

Fix

Replace the insertion sort with slice::sort_unstable_by (in-place O(n log n) introsort), capturing the first der_cmp error and returning it after the sort so error bubbling is preserved.

A few correctness points worth calling out:

• no_std: sort_unstable_by is provided by core, so it compiles under #![no_std] with no alloc. The stable sort_by would require alloc and break the heapless no-alloc build, so unstable is the right choice here. Verified the heapless feature combination compiles and tests pass.
• Ordering is identical: two elements that compare Equal under DerOrd have byte-identical DER encodings, so an unstable sort cannot change the serialized output. This is cross-checked in a test against a reference copy of the old insertion sort on both randomized and adversarial inputs.
• Duplicates are preserved: der_sort never deduplicated, and that behavior is unchanged (covered by a test).
• Non-canonical input is still accepted and sorted at decode time, unchanged.

Before / after

Decoding a reverse-sorted SET OF INTEGER:

• N=9,000: about 2,818 ms before, 0.35 ms after.
• N=18,000: about 11,414 ms before, 0.68 ms after (roughly a 16,000x improvement).

Tests

Added der_sort_matches_reference_ordering (old insertion sort vs new sort produce identical ordering on randomized and adversarial inputs), setofvec_decodes_large_reverse_sorted_der, and der_sort_preserves_duplicates. All green across default, alloc, --all-features, and --no-default-features --features heapless. cargo clippy -p der --all-features is clean. x509-cert and cms build against the change.

Out of scope

The issue also notes the SetOfVec (sorts) vs SetOfRef (rejects out-of-order) behavior difference, which a maintainer already commented on; that is a separate behavior question and is not touched here. I also did not add a hard element-count cap, since the algorithmic fix is the clean behavior-preserving change and a cap would reject currently-accepted inputs (a policy call for maintainers).