Make all stored properties in `Timecode` struct mutable

Proposal

Make all stored properties in Timecode struct mutable.

Current Conditions

Currently in 1.2.1, certain parameters are immutable and others are mutable.

struct Timecode {
    public let frameRate: FrameRate
    public let upperLimit: UpperLimit
    public let subFramesBase: SubFramesBase

    public var stringFormat: StringFormat
    public var days: Int
    public var hours: Int
    public var minutes: Int
    public var seconds: Int
    public var frames: Int
    public var subFrames: Int
}

Proposed Conditions

struct Timecode {
    public var frameRate: FrameRate
    public var upperLimit: UpperLimit
    public var subFramesBase: SubFramesBase

    public var stringFormat: StringFormat
    public var days: Int
    public var hours: Int
    public var minutes: Int
    public var seconds: Int
    public var frames: Int
    public var subFrames: Int
}

Context

In the earlier days of TimecodeKit, Timecode started as an exclusively immutable value type. This was to:

conform to the intuition that initializers that were guaranteed to succeed always produced a valid timecode and could not be changed thereafter
and conversely, failable initializers clearly indicated that a timecode was invalid and you were prevented from constructing said Timecode instance
validation was was happening actively on component value property setters (.hours, .minutes, etc.) so that invalid values were not allowed to be stored at the given frame rate and upper limit

Then as its functionality grew, it became more evident that less restrictions on the values and mutability could provide more flexibility in practise while also not sacrificing the clarity of how the object works.

The paradigm has now shifted to:

initializers still exhibit the same behavior: using overloads that consistently show how the input parameters will be parsed and validated, the outcome remains clear
- inits that are guaranteed to succeed will always produce a Timecode instance (but not all are guaranteed to produce a valid timecode, it depends on which init is used)
- inits that are failable will return nil when the inputs are not within valid constraints (or malformed, such as with a timecode String)
- inits are clearly marked with their expectations (init?(_ exactly:), init(wrapping:), init(clamping:))
in addition, init(rawValuesAt:) allows timecode component values to be set without any implicit constraints or validation for a variety of purposes
- this brings greater flexibility for a range of use-cases while not sacrificing the validation of the standard inits
- subsequently, instance methods that can then validate or return the timecode values in a variety of ways

To that end, there no longer appears to be a necessity or rationale to enforce that all or some stored properties be immutable. Since no implicit validation occurs on stored properties after the initial initialization of the Timecode struct (ie: component values are not clamped to valid values, and component values are not converted to a new frame rate when the .frameRate property changes, etc.), it is reasonable to assert that making all stored properties mutable would be intuitive and idiomatic.

orchetect / TimecodeKit