Ghidra suports user customization for instruction set extensions like WCH/QingKe. You would have to learn a little about how Ghidra's sleigh system works, patch a few files released Ghidra files under Ghidra/Processors/RISCV, then run support/sleigh to install local support for a new RISCV variant (aka 'language' in the sleigh system).

You might break down the issue into steps something like these:

1. Determine if the c.lbu, c.lhu, c.sb, and c.sh opcodes are the same as the Zcb standard extension opcodes. If so, you want the Ghidra developers to cherry pick https://github.com/thixotropist/ghidra/blob/isa_ext/Ghidra/Processors/RISCV/data/languages/riscv.zcb.sinc into Ghidra. If these opcodes have different encodings than in Zcb, add them to the list of opcodes in the next step instead.
2. The c.lbusp, c.lhusp, c.sbsp, c.shsp opcodes need to be defined in a new file named something like riscv.rv32xw.sinc. If more than one version of the XW extension set exists, you will want to support that with multiple files or embedded ifdef's.
3. Generate a new slaspec file including riscv.rv32xw.sinc and excluding the conflicting double precision floating point extensions defined in riscv.rv32d.sinc. This will be named something like riscv.lp32qingke.spaspec. You can use the AliBaba THead extension support under https://github.com/thixotropist/ghidra/tree/isa_ext/Ghidra/Processors/RISCV/data/languages as an example. Note that the THead vendor extensions are recognized by both binutils and gcc, while WCH/QingKe are not (yet?) mainstreamed.
4. Edit riscv.ldefs to enable the new language definition, so that it can appear as an import option.
5. Run support/sleigh ... to generate the sla file your local Ghidra will use to recognize the custom instructions.

The final step is to help the Ghidra developers decide how much of this should be included in the Ghidra release everyone gets, how much they should enable with extensions to the support/sleigh generator, and how much to leave as end-user customization. I am not a developer myself, so I won't second guess their decisions on that.

Thank you, that was very helpful. I've made a PR with my very preliminary implementation.

The vendor toolchain for these cores is here, but the source code to their GCC patches does not seem to be available. If you want only GCC, there are Windows binaries here. If you want macOS binaries, there are some here (direct link). Note that objdump doesn't seem to properly disassemble their own extension (even though GAS accepts it).

Their openocd fork has been successfully GPL lettered out of the MRS multiple times.
Should be possible with gcc too.