Describe the bug
Borland C++ generates switches in form of JMP word ptr CS:[BX + CaseTable],
where CaseTable is placed at the end of a function, containing the switch, and holds CS relative offsets (1 for each case) inside the function. Ghidra ignores that table and generates completely unrelated references far away from the function.

To Reproduce
Steps to reproduce the behavior:

1. Analyze the attached st.exe with the default settings.
2. Press G and enter 4b0a:09e5

Other switches there follow the same scheme and are incorrectly analyzed too.

Expected behavior
Ghidra uses the table properly to generate navigate around the switch.

Attachments
st.zip

Environment (please complete the following information):

• OS: Windows 11 23H2
• Java Version: java 17.0.7 2023-04-18 LTS
• Ghidra Version: 11.1.1
• Ghidra Origin: https://github.com/NationalSecurityAgency/ghidra/releases/tag/Ghidra_11.1.1_build

Additional context
The work around is clearing existing references by the jump's address,
and then manually adding a set of COMPUTED_JUMP references.
The one runs SwitchOverride.java at the jump's address.

It would be nice if Ghidra did some sanity checks, that the jump target lies
inside the function or anywhere near it. And if anything is suspicious,
just asking user for further input, mentioning that SwitchOverride.java script.