Split HsConDecl{H98,GADT}Details

Haskell98 and GADT constructors both use HsConDeclDetails, which includes InfixCon. But InfixCon is never used for GADT constructors, which results in an awkward unrepresentable state. This removes the unrepresentable state by:

• Renaming the existing HsConDeclDetails synonym to HsConDeclH98Details, which emphasizes the fact that it is now only used for Haskell98-style data constructors, and
• Creating a new HsConDeclGADTDetails data type with PrefixConGADT and RecConGADT constructors that closely resemble PrefixCon and InfixCon in HsConDeclH98Details. The key difference is that HsConDeclGADTDetails lacks any way to represent infix constructors.

The rest of the patch is refactoring to accommodate the new structure of HsConDecl{H98,GADT}Details. Some highlights:

• The getConArgs and hsConDeclArgTys functions have been removed, as there is no way to implement these functions uniformly for all ConDecls. For the most part, their previous call sites now pattern match on the ConDecls directly and do different things for ConDeclH98s and ConDeclGADTs.

  I did introduce one new function to make the transition easier: getRecConArgs_maybe, which extracts the arguments from a RecCon(GADT). This is still possible since RecCon(GADT)s still use the same representation in both HsConDeclH98Details and HsConDeclGADTDetails, and since the pattern that getRecConArgs_maybe implements is used in several places, I thought it worthwhile to factor it out into its own function.

• Previously, the con_args fields in ConDeclH98 and ConDeclGADT were both of type HsConDeclDetails. Now, the former is of type HsConDeclH98Details, and the latter is of type HsConDeclGADTDetails, which are distinct types. As a result, I had to rename the con_args field in ConDeclGADT to con_g_args to make it typecheck.

  A consequence of all this is that the con_args field is now partial, so using con_args as a top-level field selector is dangerous. (Indeed, Haddock was using con_args at the top-level, which caused it to crash at runtime before I noticed what was wrong!) I decided to add a disclaimer in the 9.2.1 release notes to advertise this pitfall.

Fixes #18844 (closed). Bumps the haddock submodule.