Reconsider the special case for caching read-only repeated field values

[osa1]

protobuf.dart/protobuf/lib/src/protobuf/field_info.dart

Lines 160 to 165 in 6a3e7f0

	dynamic get readonlyDefault {
	if (isRepeated) {
	return _emptyList ??= PbList.unmodifiable();
	}
	return makeDefault!();
	}

protobuf.dart/protobuf/lib/src/protobuf/field_info.dart

Lines 9 to 12 in 6a3e7f0

	/// Cached read-only empty list for this field type. For non-repeated fields
	/// this is always `null`. Otherwise it starts as `null` and gets initialized
	/// in `readonlyDefault`.
	PbList<T>? _emptyList;

I don't understand why special-case lists here. Why not also cache maps and messages? (i.e. other allocated types)

Since this field exists in all fields, it's one word overhead for non-repeated fields.

---

We find bug after bug after bug in this library because because of the special cases around types in various code. Examples:

• Freezing working different for maps and lists: PbList.toFrozenPbList does not freeze the list in-place, allows modifying frozen messages #624
• hashCode and == working differently for maps and lists: Treat empty and uninitialized Maps the same in equality checks #638
• readonlyDefault working differently for maps and lists: readonlyDefault for map fields returns mutable map #705
• presence checks working differently for bytes and other fields: Presence checks (hazzers) for optional bytes fields don't work #690

IMO a major code quality issue in this library is all these special cases about field types.

Part of the reason for these special cases is we can't introduce a class hierarchy for protobuf values as that would be a layer of indirection for "simple" field types like int32, bool, etc. which we currently represent as Dart int, bool, and so on. Performance impact of having a class PbInt32 implements PbValue would probably be unacceptable.

I think we should avoid these special cases as much as possible.