Rewrote squeeze to avoid commons-lang dependency

[DavyLandman]

I noticed we still had a commons-lang dependency. I thought we got rid of that 10y back when most of their string functions weren't safe for unicode.

There was on function still using it, so I rewrote that in regular rascal. I see no reasson to keep this in Java, unless it becomes a bottleneck.

And I added tests for it (that I first tested on the original code).

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 49%. Comparing base (cfa4c57) to head (47c7ac9).

Additional details and impacted files

@@           Coverage Diff           @@
##              main   #1992   +/-   ##
=======================================
  Coverage       49%     49%           
- Complexity    6306    6313    +7     
=======================================
  Files          664     664           
  Lines        59586   59601   +15     
  Branches      8643    8646    +3     
=======================================
+ Hits         29475   29484    +9     
  Misses       27900   27900           
- Partials      2211    2217    +6     

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

[DavyLandman]

@jurgenvinju I've rewritten it back in java.

[jurgenvinju]

Nice fix!

It's strange that we use strings for character classes while the concept is built-in to our type system. We could use #[a-z0-9] as a an actual parameter instead of a string for good measure. The formal parameter would be type[![]] class so any subset of the full Unicode 24 table. Shall we do that in another PR?

[DavyLandman]

Agreed, this function is strange to begin with. it was added 11y ago, and I cannot find a place where it's used.