Add support for immutable records

[gnarea]

Option A: Mutability at Instance Level

Should this be supported at the class or instance level? Python tends to distinguish between immutable vs mutable at the class level (e.g., set, frozenset), but I'm not convinced that's working at the right level of abstraction.

It could work at the instance level as follows:

• Record.init_as_immutable(*args, **kwargs) would be the immutable counterpart to Record.__init__(*args, **kwargs).
• Record.copy_as_immutable([...]) would be the immutable counterpart to Record.copy([...]), and it may use Record.init_as_immutable(*args, **kwargs) internally. I'm only considering this method for completeness sake, but I can't think of a good use case for it -- Maybe it shouldn't be created just yet.
• Record.copy([...]) will unconditionally return an mutable copy, which makes me uncomfortable but I think it'd be a good compromise. Otherwise, if you already have an immutable record, why on earth would you like to get another shallow, immutable copy of it?
• Record.is_mutable would be a read-only property that does what it says on the tin. This makes me uncomfortable because the syntax suggests that "is_mutable" is a field in the record type.
• Equality tests between an immutable and mutable record of the same type and with the same data: Should they evaluate to True? I think so, but again, not strictly correct.
• As implied by the interface changes above, an immutable record instance cannot be made mutable, but you could get a mutable copy.
• Encourage users to use immutable records whenever they retrieve the data from external sources (e.g., web service, device data over USB). If any client of their library wants to return the record changed, it makes sense to leave the original unchanged and instead send a modified copy.

One thing I don't like is the number of methods that will be added -- and creating functions would just be a cheeky workaround as it'd be no different from a ADT-centric view.

Option B: Immutable Records Only

I'm increasingly convinced that namedtuple got this bit right: Records should be immutable. Immutable objects can be hashed, are thread-safe and, more importantly, there's exactly one place where fields are set (initialization; so no nasty surprises).

Fields would be "changed" by copying the record (#2). Some people say this harms performance and the ability to do garbage collection; I think the former shouldn't be noticeable at all and the latter is just wrong.

From the 2 years of experience using this library, I think I've rarely had to change a record and, of those few times, most were due to #2.

Ada's tagged records are immutable, which makes me confident that at least this isn't a stupid idea.

If I go for this option, I'd have to release a major version (v2) because it'd be backwards incompatible, accompanied with a v1.1 that's backwards-compatible and supports immutable records.