[ty] do nothing with store_expression_type if inner_expression_inference_state is Get

[mtshiba]

Summary

Fixes astral-sh/ty#1688

Test Plan

N/A

[astral-sh-bot]

Diagnostic diff on typing conformance tests

No changes detected when running ty on typing conformance tests ✅

[astral-sh-bot]

mypy_primer results

Changes were detected when running on open source projects

scikit-build-core (https://github.com/scikit-build/scikit-build-core)
+ src/scikit_build_core/_logging.py:153:13: warning[unsupported-base] Unsupported class base with type `<class 'Mapping[str, Style]'> | <class 'Mapping[str, Divergent]'>`
- Found 41 diagnostics
+ Found 42 diagnostics

pandas-stubs (https://github.com/pandas-dev/pandas-stubs)
+ pandas-stubs/_typing.pyi:1207:16: warning[unused-ignore-comment] Unused blanket `type: ignore` directive
- Found 5806 diagnostics
+ Found 5807 diagnostics

No memory usage changes detected ✅

[MichaReiser]

Could we use multi_inference_state::Ignore instead of having two modes that represent "read-only" type inference?

[Gankra]

drive-by context: I am likely to modify this check for in_string_annotation to do the "store (Expr, Expr) for string annotation types" thing we've been discussing.

[mtshiba]

Could we use multi_inference_state::Ignore instead of having two modes that represent "read-only" type inference?

I understand that MultiInferenceState::Ignore is an option to perform the same calculation twice and discard the second result.
Since all type inference for expressions is skipped while in InnerExpressionInferenceState::Get, I think it should be used whenever possible (for example, when only diagnostics are needed, such as the handling in infer_subscript_type_expression for union types).
But I'm not sure whether this can be assumed in all cases where MultiInferenceState::Ignore is used.