Return early if map type mismatch in buf lint protovalidate

[oliversun9]

This PR fixes an issue where buf lint crashes when map rules are defined on a non-map field:

  int32 not_a_map = 14 [
    (buf.validate.field).map.values.int32.lt = 10,
    (buf.validate.field).map.values.int32.gt = 1
  ];

The fix is to return early if type mismatches.

[rodaine]

Are we returning a lint warning/error for this otherwise? (And do we need to handle repeated rules on singular fields as well?)

[bufdev]

Should this produce two lint errors l, one for each of the two mismatched annotations?

[oliversun9]

The two lines belong to the same rule, (buf.validate.field).map.

When we pass the path (buf.validate.field).map to OptionExtensionLocation, the location we get back is just the first line. Ideally we get a location back that covers both lines.

I think it's due to the way sourceCodeLocations are generated by the compiler -- there isn't a location that spans both lines exactly.

[oliversun9]

We are also not able to tell whether the option is specified in two lines or in the aggregate form.

On a high level, the linter cannot tell

  int32 not_a_map = 14 [
    (buf.validate.field).map.values.int32.lt = 10,
    (buf.validate.field).map.values.int32.gt = 1
  ];

from

  int32 not_a_map = 14 [(buf.validate.field).map.values.int32 = {lt: 10, gt: 1}];

[oliversun9]

Are we returning a lint warning/error for this otherwise?

Now we return a lint warning saying you have map rules for a non-map field. We don't further check whether a the map rule's key and value sub rules are valid. For example, it's impossible to check whether the map rule's key rule typechecks.

[bufdev]

Approved assuming @rodaine comment addressed