[wip] gogensig: typedef havent defined type cause panic

[luoliwoshang]

#61

gnutls/gnutls.h

typedef enum gnutls_cipher_algorithm {
	GNUTLS_CIPHER_UNKNOWN = 0,
	GNUTLS_CIPHER_NULL = 1,
} gnutls_cipher_algorithm_t;

#include <gnutls/compat.h>

gnutls/compat.h

typedef gnutls_cipher_algorithm_t gnutls_cipher_algorithm
	_GNUTLS_GCC_ATTR_DEPRECATED;

经过调查，发现是因为在gnutls/gnutls.h的底部，才引入<gnutls/compat.h>,而目前的处理逻辑是，对于一个头文件，先处理其include列表，处理结束后，才会处理本来的头文件，这就导致了gogensig 先处理gnutls/compat.h 的时候，gnutls_cipher_algorithm_t这个类型还没定义

可能的解决方案

llcppsigfetch 中能正确获得gnutls/compat.h中underlying type的原因是其遵守了C编译顺序，即先完成了类型的定义，再执行了include引入，所以这个引用顺序是没有错误的，能正确描述类型定义。而gogensig的头文件依赖关系的处理为无论这个include节点的位置在某个头文件的何处，都会先访问被include的文件。

目前存在两种解决方案

1. 将gogensig的处理头文件的顺序，修改处理为与C语言的一致，即将include节点视为一个一般的声明节点，存在顺序，碰到include节点，就先处理对应include的文件转换，这个能保证更能正确的描述C语言的结构。

   • 经过尝试，发现获得的include并不是按照源文件顺序 da2f978

2. 不修改整体处理逻辑，但补充处理到某个类型时，查看其对应节点的定义位置的头文件，是否已经被处理，如果没有被处理，那就优先访问转换。

• llcppsigfetch：保留位置信息，处理到某个类型时，查看其头文件是否已经被处理，如果对应类型某个头文件还没访问，那么优先处理对应的头文件。对于这个用例来说，即检查这个gnutls_cipher_algorithm_t 对应的头文件是否被处理，如果没有被处理，那么先处理该文件。

• 正在考虑与Go一致，llcppsigfetch提供一些类型信息，用于存放映射或者定义关系

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 97.47%. Comparing base (33cca25) to head (9e256c0).
Report is 1 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main      #88   +/-   ##
=======================================
  Coverage   97.47%   97.47%           
=======================================
  Files          15       15           
  Lines        1822     1822           
=======================================
  Hits         1776     1776           
  Misses         32       32           
  Partials       14       14           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.