[Optimization/Feature] Add ColorRectAndBorderTexture for combined rendering

[DeusSixik]

Problem:
Currently, rendering a standard UI panel with both a solid background and a border requires allocating and processing two separate textures (ColorRectTexture and ColorBorderTexture). This forces developers to use IGuiTexture[] arrays, creating unnecessary object allocations and adding overhead to the UI rendering hot path.

Solution:
Introduced ColorRectAndBorderTexture - a single IGuiTexture implementation that handles both the background fill and the border stroke in one pass.

P.s. I might have made an incorrect translation into Chinese, so please check it for accuracy.

[Tcat2000]

So I'm wondering if this is really necessary. Why would you need to use a color rect in the middle? Why not just stretch a single pixel of across the entire middle, or if you edges are longer, just fill it with the desired color. Right now it feels like something either unnecessary, or something very specific to your project, that's not good justification to add it to the base mod. If your writing your project in (kube)JS or Java, you can make this feature your self.
Additionally, is creating an array that big of a deal? Like if one more array for the background texture has a measurable impact on performance, then what is a detailed GUI with many arrays doing to your performance?

[DeusSixik]

Thanks for the review and the valid questions! Let me clarify the motivation behind this PR, as I realize my initial description overemphasized the array allocation issue.

1. Why not just stretch a single pixel? (The procedural aspect)

I completely agree that for sharp, rectangular boxes, stretching a 1x1 pixel is the best approach. However, this PR specifically targets procedural rounded corners. In modern UI design, a rounded panel with a background fill and a distinctly colored border stroke is a fundamental primitive (essentially standard CSS).
Currently, to achieve a smooth, anti-aliased rounded box with a border in LDLib, we must use ColorRectTexture and ColorBorderTexture. Stretching a static image cannot replicate the dynamic border-radius provided by LDLib's shaders.

2. The real performance benefit: GPU Draw Calls, not GC

You are absolutely right about the array allocation - if the UI is properly cached during initWidget, the GC impact is non-existent. My apologies for framing it that way.
The actual optimization is on the GPU rendering side. Rendering a fill and a border currently requires two separate shader passes (DrawerHelper.drawRoundBox and DrawerHelper.drawFrameRoundBox). A combined ColorRectAndBorderTexture allows doing both in a single pass. In a complex UI with hundreds of rounded slots or panels (like a large shop grid or inventory), halving the background draw calls is a measurable optimization for the rendering thread.

3. Scope (Core vs Project-specific)

I proposed this to the base mod because "Background + Border + Border Radius" is a universally standard UI component, not something specific to my project's business logic. It felt like a natural missing piece in the gui.texture package to improve developer ergonomics.

That being said, if you feel this feature is redundant or bloats the core library's scope, I completely understand! I can easily implement it as a custom IGuiTexture within my own project. Let me know what you decide, and feel free to close the PR if it doesn't align with your vision for LDLib.

[Tcat2000]

Alright, I see now. I was not actually aware that you could do rounded corners in the ColorBoarderTexture!
So does it make since to make an entirely new class for this feature? If I understand correctly, the same functionality could be achieved by adding a background color to ColorBoarderTexture, that just defaults to 0 alpha. As long as this does not break any existing textures, then that will be a much cleaner way to add this.