Rename Error message methods in Preconditions to describe their action

[ArthurVCristiano]

This pull request renames two private methods in Preconditions.java:

• badElementIndex() → formatElementIndexMessage()
• badPositionIndex() → formatPositionIndexMessage()

The names badElementIndex and badPositionIndex describe a situation
(a bad index) rather than the action the method performs (formatting an
error message). This violates a fundamental naming convention in Java:
method names should describe what the method does, not the context that
triggered it.

The Guava codebase itself follows this convention consistently across
other utilities. A reader encountering badElementIndex() must inspect
the implementation to understand that it builds and returns an error
message string — the name alone does not communicate this.

The proposed names formatElementIndexMessage() and
formatPositionIndexMessage() make the intent immediately clear:
these methods format a message to be used when an index is invalid.

This change was motivated by an empirical analysis of Google Guava
across 20 releases (v10.0 to v29.0), in which Rename Method appeared
among the top 10 most frequent refactoring types detected by
RefactoringMiner. The analysis also showed a consistent growth in WMC
(ρ = +0.818, p < 0.001), indicating that classes have been accumulating
complexity over time. Improving method naming is a low-cost, high-impact
practice to counteract this trend, reducing cognitive overhead for
readers and maintainers.

[cpovirk]

The JDK uses "outOfBoundsMsg,", so I'm not sure what our excuse is :) Or actually, it's possible that the naming of badPositionIndex, at least, is meant to hint that the method sometimes throws directly instead of returning a string. (But the hint wasn't enough to keep me from confusing myself about it a few months back.)

There may be something that could improve matters here. It's just not immediately crystal clear to me what that should be.