Release v1.1.0 — Dictionary leniency · EngOmarElsayed/swift-lenient-codable

Per-entry lenient dictionary decoding

@LenientDecodable structs can now decode dictionary properties leniently — one broken entry no longer takes down the other 99.

@NilOnFailure (or the implicit default) on [K: V?] — value padding: a broken value becomes nil at its key, the rest of the dictionary survives. [K: V?]? decodes absent/unusable dictionaries as nil instead of [:].
@DropOnFailure on [K: V] — broken entries are removed, survivors keep their keys.
LenientDictionaryKey — the string→key contract (a decode-only, failure-tolerant analogue of CodingKeyRepresentable, back-deployed to iOS 13). String and Int conform out of the box; enum keys opt in with one line:
```
extension Status: LenientDictionaryKey {}
```
Unknown enum keys drop their entry instead of failing the whole decode.
Key failures always drop their entry (reported to the debug logger with the raw JSON key) — a key has no nil-shaped hole to pad.
New compile-time diagnostics with fix-its for invalid shapes: non-optional values under padding, optional values under drop, optional keys ([K?: V]), and Dictionary<K, V> longhand.
Dictionary overloads of the LenientDecoding runtime helpers, callable from hand-written init(from:) too.

A lenient [K: V]? property (non-optional values) that compiled under 1.0.0 with whole-value leniency now produces a compile-time error with fix-its — apply the fix-it to [K: V?]? for per-entry padding, or mark it @Strict to keep synthesized behavior.
A lenient [K: V?]? property now pads per entry instead of nil-ing the whole dictionary when a single entry is broken. If you relied on whole-value semantics, mark the property @Strict.
@Strict dictionary properties are untouched — byte-for-byte synthesized behavior.

Full Changelog: v1.0.0...v1.1.0