fix(resnames): ensure determinstic code generation

[chanseokoh]

Fixes #847.

Certainly, there are other alternative approaches to fix this issue in other places, but I think this is reasonable. GapicContext will consistently return resource names in a deterministic way, no matter what the input is.

This also reverts the fix in #813 that resolved the same issue for sample code generation, which is made obsolete by this PR. Note, the previously updated golden files in #813 are not reverted, proving that this PR is enforcing the same order without #813.

[codecov]

Codecov Report

Merging #865 (cf22ae6) into main (23e4a36) will decrease coverage by 0.00%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##             main     #865      +/-   ##
==========================================
- Coverage   87.60%   87.59%   -0.01%     
==========================================
  Files         152      152              
  Lines       15988    15982       -6     
  Branches     1162     1162              
==========================================
- Hits        14006    14000       -6     
  Misses       1641     1641              
  Partials      341      341              

Impacted Files	Coverage Δ
...er/samplecode/ServiceClientSampleCodeComposer.java	99.28% <ø> (-0.01%)	⬇️
...rator/gapic/protoparser/MethodSignatureParser.java	94.73% <ø> (ø)
...google/api/generator/gapic/model/GapicContext.java	95.23% <100.00%> (+0.50%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 23e4a36...cf22ae6. Read the comment docs.

[meltsufin]

LGTM, but see one minor comment.

[meltsufin]

I'm not very familiar with Autovalue, but can you just do this in the GapicContext.resourceNames() getter with @Memoized?

[chanseokoh]

I'm totally new to AutoValue, and you may know better than I do. I tried to look up a way to achieve what I wanted to do, and this was basically the only way I could think of. I looked into @Memoized, but I think conceptually it's more appropriate to use for caching to solve a problem with an expensive operation. And the doc seems to suggest that I need another "derived method" to use @Memoized (though I am not sure). build() is called only once and new TreeMap<> is a simple thing to do, so I think storing the converted value at the beginning works and is more robust without any magic.