This is an alternative to #980 that doesn't make a big difference in
terms of performance of AOT compiled benchmarks, but makes a big
difference when compiling to Wasm, comapred to #980.

When decoding an enum value, we call a callback in the enum field's
`FieldInfo`. The callback then indexes a map mapping enum numbers to
Dart values.

When these conditions hold:

- The known enum numbers are all positive. (so that we can use a list
  and index it with the number)

- The known enum numbers are more than 70% of the large known enum
  number. (so that the list won't have a lot of `null` entries, wasting
  heap space)

We now generate a list instead of a map to map enum numbers to Dart
values.

Note: similar to the map, the list is runtime allocated. No new code
generated per message or enum type.

Wasm benchmarks:

- Before: `protobuf_PackedEnumDecoding(RunTimeRaw): 48200.0 us`
- PR #980: `protobuf_PackedEnumDecoding(RunTimeRaw): 42120.0 us`
    - Diff: -12.6%
- After: `protobuf_PackedEnumDecoding(RunTimeRaw): 35733.3 us`
    - Diff against PR #980: -15%
    - Diff against master: -25%

AOT benchmarks:

- Before: `protobuf_PackedEnumDecoding(RunTimeRaw): 49180.0 us`
- PR #980: `protobuf_PackedEnumDecoding(RunTimeRaw): 45726.82 us`
    - Diff: -7%
- This PR: `protobuf_PackedEnumDecoding(RunTimeRaw): 42929.7 us`
    - Diff against PR #980: -6%
    - Diff agianst master: -12%

…ng_2

With upcoming change we'll improve decoding performance of enums, but
there will be a difference between "sparse" and "dense" enum decoding
performance even though they'll both be faster.

To be able to measure the difference add a "sparse" enum type and a
benchmark for decoding it.

"Sparse" means the enum has large gaps between known enum values, or
negative enum values.

When decoding this kind of enums, the mapping from the wire `varint` to
the Dart value for the enum needs to be done by binary search, map
lookup, or similar.

For "dense" enums, we can have a list of enum values and index the list
directly with the `varint` value, after a range check.

These changes will be done in the follow-up PR(s).