Remove unnecessary use of NoInlining and add traceability for valid uses, #931

[paulirwin]

• You've read the Contributor Guide and Code of Conduct.
• You've included unit or integration tests for your change, where applicable.
• You've included inline docs for your change, where applicable.
• There's an open issue for the PR that you are making. If you'd like to propose a change, please open an issue to discuss the change or find an existing issue.

Remove unnecessary use of NoInlining and add traceability for valid uses

Fixes #931

Description

This removes over 100 uses of NoInlining that did not trace back to actual usage in tests that inspect the stack trace, which unnecessarily harm performance. To determine this, debugging and code review was used to find which methods were actually being expected in the stack trace. Once the expected method was determined, the string literal of the method name was replaced with the nameof operator for go-to-definition traceability back to the method (or multiple overloads, in some cases) in question. Likewise, a comment was added on the use of NoInlining on the method to explain which test(s) needed this attribute. This way we have two-way traceability to help prevent accidental removal in the future. This could be improved with a custom dev analyzer and suppression in the near future.

One case remains, in PreFlexRWTermVectorsFormat, where I could not hit a breakpoint in tests that use this type, so I am not sure that it is actually needed. This was left as-is with a LUCENENET TODO comment. I presume it is likely expecting SegmentMerger.Merge like the similar PreFlexRWPostingsFormat, but I couldn't determine this for sure.

This PR is currently in draft status to ensure all tests pass. I'll publish it once I get extra validation that the removals are correct through multiple test runs.

[paulirwin]

Build succeeded on ADO (after retrying an unrelated flaky test failure) as well as GitHub. Publishing PR for review.

[NightOwl888]

Thanks for the PR. Looks good except I think we should check whether we differ from Lucene in the PreFlexRWRTermVectorsFormat test. If Lucene also behaves this way, I think we should just leave it as is.