Fix or workaround recent extension API compatibility issues

[akien-mga]

• Add compatibility methods for RenderingDevice::shader_create_from_bytecode (follow-up to ShaderRD compilation groups #79606) and CodeEdit::get_text_for_symbol_loopup (follow-up to Fix jumping to function definition using Ctrl+LMB or the "Lookup Symbol" button #73196).
• Silence errors which now have compatibility methods.
• Acknowledge GraphEdit/GraphNode compat breakage, intended and WIP (follow-up to Clean up/refactor GraphEdit #79308).

Draft as I'm still getting this error despite the compat method I added:

Validate extension JSON: Error: Field 'classes/RenderingDevice/methods/shader_create_from_bytecode/arguments': size changed value in new API, from 1 to 2.

[akien-mga]

So #78328 added compat code for TileMap.get_used_rect which was made const, but previous compat checks added in 4.1 all handled const changes as a non-breaking change. That's also what I did in this PR.

So which is it? Do we need compat bindings for non-const methods which were made const?

And why doesn't the compat binding work for RenderingDevice.shader_create_from_bytecode?

[akien-mga]

These didn't seem necessary, so I simplified. Otherwise it looked like these were ordered this way with a separation to solve a recursive inclusion issue (since object is already included in class_db), but since it compiles fine without it I guess it was a remnant from previous architectures.

[dsnopek]

So which is it? Do we need compat bindings for non-const methods which were made const?

We do need a compatibility method for changes to const-ness, because it changes the hash which breaks GDExtension.

It appears godot --validate-extension-api will emit two separate messages for this change: one about the hash (which adding the compatibility method will fix) and another separate one about the change from non-const to const.

From the perspective of GDExtension, all that matters is the hash. We could remove the specific check for is_const and just rely on the hash mismatch? Although, then it might be hard to figure out why the hash doesn't match. :-) If it were possible to make it not emit any other messages if the hashes were good, that would be ideal, but looking at how this is implemented, that doesn't seem easy to add, since it's basically just comparing the raw data from the extension_api.json.

As it is currently, it seems that you need to do what you did, which is add an exception for the additional message about const-ness change.

[akien-mga]

I'll try adding the non-const compat methods and see if that solves both errors.

[akien-mga]

OK, so I added the two compat methods which were missing for the hash mismatches reported by the tool.

And indeed it seems the tool still reports compatibility breaking changes even after adding compat methods, so those reports need to be silenced manually by adding them to the file anyway. Did we get it right @RedworkDE?

[RedworkDE]

And indeed it seems the tool still reports compatibility breaking changes even after adding compat methods, so those reports need to be silenced manually by adding them to the file anyway. Did we get it right @RedworkDE?

Well the tool reports all API changes compared to a given version (with some minor exceptions). Adding the compatibility method only suppresses the error about the hash change of the method as that is the only thing that adding a compat method fixes. The underlying method still has changed and that change is still reported as it might still be an issue for use-cases other than godot-cpp.

TL/DR: Yes.

---

Changes look correct and as expected to me.
I still have Ideas for general improvements (primarily actually checking against 4.1, without duplicating everything) but I'll get to them soon(tm) in a different PR.