zeekygen_next_comment attached to wrong scope

[bbannier]

In order to extract docstrings over in https://github.com/bbannier/zeek-language-server I check for any direct previous siblings which are zeekygen_next_comment. This breaks for e.g., enums, see bbannier/zeek-language-server#87.

type E: enum {
	## A.
	A,
};

$ tree-sitter parse enum.zeek
(source_file [0, 0] - [4, 0]
  (decl [0, 0] - [3, 2]
    (type_decl [0, 0] - [3, 2]
      (id [0, 5] - [0, 6])
      (type [0, 8] - [3, 1]
        (nl [0, 14] - [1, 0])
        (zeekygen_next_comment [1, 1] - [1, 6])
        (nl [1, 6] - [2, 0])
        (enum_body [2, 1] - [2, 3]
          (enum_body_elem [2, 1] - [2, 2]
            (id [2, 1] - [2, 2])))
        (nl [2, 3] - [3, 0]))))
  (nl [3, 2] - [4, 0]))

The issue here is that zeekygen_next_comment is an extras node which can appear anywhere. Since enums always contain a redundant enum_body (which corresponds to nothing in the source), Tree-sitter opts to inserts the comment before the body instead of inside the body before the first element, so the comment is not a sibling of the value it documents. One fix for this would be to omit enum_body from the grammar or at least the CST so we more directly reflect what is in the source.