Add MoreCollectors.to*WithExpectedSize helpers

[schlosna]

WIP Draft for comments

Some questions came up about providing Stream collectors that avoid some of the growth & reallocation overhead of JDK standard collectors such as Collectors.toList() and where libraries are targeting JDK 11 so cannot use Stream::toList() added in JDK 16.

This typically only matters in more allocation sensitive code in which case use of Guava Collections2.transform, Lists.transform, Maps.transformValues may be better solutions to avoid the intermediate collection copy; however, there are some cases where one must make a copy (e.g. if the elements being transformed are only valid inside a transaction), so providing these mechanisms may be beneficial.

Questions:

• Do we want to encourage use of these?
  • If used with filter, these likely over-allocate in what one might assume are performance/allocation sensitive paths.
  • For the places these matter, should we be encouraging other non-Stream implementation?
• Are these worth the API burden & support?
• Is this the place we'd want to land these?
  • Do we want to use MoreCollectors as that conflicts with simple type name for com.google.common.collect.MoreCollectors?

[changelog-app[bot]]

Generate changelog in changelog/@unreleased

Type

• [ ] Feature
• [x] Improvement
• [ ] Fix
• [ ] Break
• [ ] Deprecation
• [ ] Manual task
• [ ] Migration

Description Add MoreCollectors.to*WithExpectedSize helpers

Check the box to generate changelog(s)

• [x] Generate changelog entry

[schlosna]

Curious for thoughts on these additions given some recent places these could be used