Fix large list bytecode estimation by removing sampling

[fglock]

Problem

ExifTool's %Image::ExifTool::Extra hash (2,576 elements) was causing "Method too large" JVM errors.

Root cause: Bytecode size estimation was using sampling (only 10 elements) instead of estimating all elements, leading to severe underestimation: 31,684 bytes estimated vs actual >65KB.

Solution

1. Removed Sampling from LargeNodeRefactorer.shouldRefactor()

• Changed from sampling 10 elements to estimating all elements
• Provides accurate bytecode size calculation for mixed element types
• Now correctly estimates 2,576-element list at 85,465 bytes → triggers refactoring

2. Fixed BytecodeSizeEstimator for Proper Visitor Pattern

• ListNode: Only adds list overhead (DUP + add call = 5 bytes per element)
• StringNode: Fixed to 6 bytes (LDC + INVOKESTATIC) based on actual disassembly
• Elements estimate themselves via visit() - no special cases or multipliers
• Added constant pool overhead for large lists (LDC_W costs 3 bytes vs 2)

3. Code Cleanup

• Removed experimental codegen-time refactoring from EmitLiteral.java
• Removed all debug trace statements
• Refactoring happens only at parse time (as designed)

Result

• 2,576-element list now correctly refactored into 72 chunks at parse time
• Accurate bytecode estimation without sampling
• Proper visitor pattern - elements estimate themselves
• Prevents JVM "Method too large" errors for large Perl data structures