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

https://github.com/google/protobuf.dart/blob/6a3e7f024a46b9353fd172abe2b80125244cae45/protobuf/lib/src/protobuf/field_info.dart#L160-L165

https://github.com/google/protobuf.dart/blob/6a3e7f024a46b9353fd172abe2b80125244cae45/protobuf/lib/src/protobuf/field_info.dart#L9-L12

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: #624
- `hashCode` and `==` working differently for maps and lists: #638
- `readonlyDefault` working differently for maps and lists: #705
- presence checks working differently for `bytes` and other fields: #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.

Read protobuf/lib/src/protobuf/field_info.dart at the referenced lines, then trace how the field is used for repeated values and other allocated types. Compare the existing handling of lists, maps, messages, and scalar fields; this issue is done only after the design question has a decided, consistent scope and corresponding validation.

Written by the indexing model from the issue text.