Handle extra semicolons after import statements

[saranshflip]

What's changed?

Added debug test to investigate Java parser behavior with consecutive semicolons in import statements. Enhanced parser to detect and consume extra semicolons following import statements, storing them in the whitespace for accurate source representation.

What's your motivation?

Investigating a parsing issue where consecutive semicolons in import statements (e.g., import java.util.*;;) cause parser failures or generate incorrect LST with J.Erroneous nodes. This test helps identify the root cause and validates potential fixes.

Anything in particular you'd like reviewers to focus on?

Current Status: The parser now bypasses the parsing error and generates an LST tree, but the tree contains J.Erroneous nodes which indicates the fix is incomplete.

Key concerns:

• The LST structure is not correctly representing the consecutive semicolons
• J.Erroneous nodes suggest the parser is still struggling with this syntax
• Need guidance on proper tree generation for this edge case

Would appreciate feedback on:

• Correct approach to handle extra semicolons in the grammar/parser
• How to properly store consecutive semicolons in the LST without creating erroneous nodes
• Whether the whitespace approach is the right strategy

Anyone you would like to review specifically?

Looking for maintainers familiar with the Java parser implementation and LST tree generation.

Have you considered any alternatives or workarounds?

1. Current approach: Storing extra semicolons in whitespace partially works but creates erroneous nodes
2. Alternative: Modifying the grammar to explicitly handle consecutive semicolons
3. Workaround: Pre-processing source to normalize consecutive semicolons before parsing

Any additional context

This is a work-in-progress contribution. The debug test successfully identifies the issue and the current fix prevents parse failures, but the LST generation needs refinement. The test includes comprehensive debugging output to help understand the parser's behavior with malformed import statements.

Test output shows:

• Parser no longer fails completely
• LST tree is generated but contains erroneous nodes
• Source round-trip may not be perfect due to incorrect tree structure

Seeking guidance on the proper implementation to generate a clean LST without J.Erroneous nodes.

[timtebeek]

Given the fall through from above this should probably become it's only block below THROW.

[timtebeek]

Let's move these prints into spec.afterRecipe in the unit test, and not here in the parser.

[timtebeek]

We've since seen this parallel alternative fix go in

• Java: Fix parsing of extra semicolons after imports #7138

Thanks again!