Fix malformed XML doc comments from BBCode inside code blocks

[cobriensr]

Problem

When the bindings generator converts Godot's BBCode documentation into C# XML doc comments, recognized inline tags ([b], [i], [u], [br], [url], …) are emitted as real XML elements even inside a [codeblock]/[csharp] block. Text that merely looks like a tag, most commonly an array subscript such as a[i] in shader code is turned into a stray <i> element, producing unbalanced XML.

For example, VisualShaderNodeColorOp's OP_OVERLAY docs contain:

result[i] = 2.0 * base * blend;

which generated result<i> = 2.0 * base * blend; inside <code>, so compiling Godot.Bindings with GenerateDocumentationFile=true fails with errors like:

error CS1570: XML comment has badly formed XML -- 'End tag 'code' does not match the start tag 'i'.'

Fix

• Hoist the existing code-context guard above both the start-tag and end-tag switches in XmlDocConverter, so that inside a code context every tag except the ones that manage the code state (codeblock/codeblocks/csharp) is preserved as literal text, matching how unrecognized tags were already handled.
• Reset the code-element state (inCodeTag) when closing a [csharp]/[codeblocks] block. Previously it was left set, so prose following a [codeblocks] block was treated as if still inside a code block (a latent bug the guard above would otherwise have made visible in trailing prose).

Tests

Added to XmlDocConverterTests:

• Array subscripts (a[i], result[i]) preserved literally inside [codeblock].
• Recognized inline tags ([b], [i]) preserved literally inside [codeblock].
• Inline [code] round-trips BBCode-looking content.
• [codeblocks] keeps the [csharp] half and drops the [gdscript] half, with subscripts preserved.
• Prose after a [codeblocks] block is no longer treated as in-code (a trailing [b] renders as <b>).

dotnet test tests/Godot.BindingsGeneration.Tests passes (13 converter tests, including the pre-existing ones).

Scope

This addresses the malformed-XML (CS1570) category only. Other generated-doc issues surfaced by GenerateDocumentationFile=true like ambiguous cref references (CS0419) for overloaded methods are independent and left for separate follow-up.