Add a new macro LossyCodable

[wzio]

This library is very exciting, but I believe a LossyCodable Macro could be created to further simplify some of the code.
The LossyCodable could automatically apply @CodedBy(ValueCoder<T>()) to each basic Codable property, removing the need to manually add the attribute on every property.
The custom models and custom HelperCoders would still need to be handled separately.

@Codable
fileprivate struct Model {
    @CodedBy(ValueCoder<Bool>())
    let bool: Bool
    @CodedBy(ValueCoder<Int>())
    let int: Int
    @CodedBy(ValueCoder<Double>())
    let double: Double
    @CodedBy(ValueCoder<String>())
    let string: String
}

to

@LossyCodable
fileprivate struct Model {
    let bool: Bool
    let int: Int
    let double: Double
    let string: String
}

I'm interested to hear your thoughts on this idea or any suggestions

[soumyamahunt]

@wzio I have few questions on this suggestion:

• Why the name LossyCodable?
• What do you think the behaviour should be for any field having type that doesn't conform to ValueCodingStrategy, i.e. Date?
• How many models do you have that can be simplified with such feature?

[wzio]

• Well, the name "Lossy" for this feature comes from LosslessStringConvertible. Compared to basic String convertible, ValueCodingStrategy loses the original JSON types, especially during decoding. So I called it "Lossy", but names like "SafeCodable" would also work - I'm open to suggestions.

• If a field does not have a ValueCodingStrategy specified, such as Date or Data fields, it will be ignored and use the default Codable strategy. However, if @CodedBy(HelperCoder) is specified on a field, then that custom HelperCoder will be used for encoding/decoding.

• Our backend API uses loosely typed PHP without good conventions for converting between strings, integers etc. This means we need to handle these string conversions in almost every api model

[soumyamahunt]

Discussed in #93