clean: mark all Idxheader packed explicitly

[shenlebantongying]

close #1576

This PR does absolutely nothing technically, because removing these packing compiler directives is OK 😅😅😅.

In both 32 & 64 bits machines, a struct with all 32bit fields will be already “packed” (This doesn't appear to be in the standard, but it is what all 3 major compilers do).

However, this PR makes code's purpose clear (Not really, because only after reading the code, one would know that GD is using this trick to read/write multiple fields at once) and reduce inconsistency (It is pretty weird to see the inconsistency as showed in #1576.).

---

This PR also removes gcc and clang's __attribute__((packed))__ because they both of them supports #pragma pack(push, 1) -> #pragma pack(pop) since ages ago (In fact, clang has a warning about incomplete pair of push/pop).

I tested this code https://godbolt.org/z/YvWvsf9ad for compilers that we care (the one in Debian stable & Ubuntu 22.04 and some older ones). To ensure this certainly works, I added a harmless static_assert for every idxHeader.

---

This PR corrected 2 inconsistent int in dsl.cc and gsl.cc. This change is correct because based on this table the int type is 32bit anyway (https://en.cppreference.com/w/cpp/language/types#Properties).

[sonarqubecloud]

Quality Gate failed

Failed conditions
B Maintainability Rating on New Code (required ≥ A)

See analysis details on SonarCloud

Catch issues before they fail your Quality Gate with our IDE extension SonarLint

[xiaoyifang]

what about alignas https://learn.microsoft.com/en-us/cpp/cpp/alignas-specifier?view=msvc-170
seems more elegant.

[shenlebantongying]

They aren't exact the same, despite that they can often use interchangeably.

See the error in 4th snippet -> https://godbolt.org/z/scMKE1EME (clang says it is an error 👍 . GCC silently ignored it❗. MSVC warns that alignas will be ignored 😅)

• alignas still follow some rules
• pack is for violating these rules to make things compact

However, for idxHeader, there is no difference, because not using any of these things is also OK (but that could be risky).

I don't want to change this anymore. The original issue of "inconsistency that oddly looks like a potential source of bug" is fixed.