Add LuaJIT backward compatibility integration tests

**If you are reporting *any* crash or *any* potential security issue, *do not*
open an issue in this repo. Please report the issue via emailing
envoy-security@googlegroups.com where the issue will be triaged appropriately.**

*Title*: *Add LuaJIT backward compatibility integration tests*
*Area*: Lua filter, Testing

*Description*:

**Problem:**

The Envoy Lua filter (`envoy.filters.http.lua`) allows users to execute custom Lua scripts, and it relies on LuaJIT for script execution. The LuaJIT dependency is periodically updated in `bazel/repository_locations.bzl` to incorporate new features, performance improvements, or security fixes.

Currently, there are no integration tests specifically designed to detect regressions or behavioral changes in LuaJIT's standard libraries (`table`, `string`, `math`, `bit`, etc.) when the version is upgraded. A future LuaJIT upgrade could inadvertently introduce subtle, backward-incompatible changes that break users' existing Lua scripts, which rely on the consistent behavior of these libraries.

**Proposed solution:**

To mitigate this risk and make future LuaJIT upgrades safer, we should introduce a new integration test case to `test/extensions/filters/http/lua/lua_integration_test.cc`. This test will be dedicated to verifying LuaJIT backward compatibility by executing a script that uses commonly relied-upon language features and library functions, then asserting that their output remains as expected.

This test should cover features such as:

* Table iteration behavior (e.g., `ipairs`)
* String manipulation (e.g., `string.gsub`)
* Math functions (e.g., `math.floor`)
* Bitwise operations via the LuaJIT `bit` library (e.g., `bit.band`)
and so on...

Adding this targeted test case will provide greater confidence that LuaJIT upgrades do not introduce breaking changes for users of the Lua filter.

**Example Implementation:**

A new test case, `LuaJITBackwardCompatibility`, can be added to `LuaIntegrationTest`. This test would configure the Lua filter with inline code that exercises the features mentioned above and writes the results to request headers. The test would then verify that the upstream request headers contain the expected values.

```lua
-- Example Lua code for the test
function envoy_on_request(request_handle)
-- table iteration
local t = {"a", "b"}
t[5] = "e"
local str_ipairs = ""
for i,v in ipairs(t) do
str_ipairs = str_ipairs .. i .. v
end
request_handle:headers():add("compat_ipairs", str_ipairs) -- expected: 1a2b

-- string.gsub
local s = "hello world"
s_gsub = string.gsub(s, "l", "L")
request_handle:headers():add("compat_gsub", s_gsub) -- expected: heLLo worLd

-- math.floor
request_handle:headers():add("compat_math_floor", tostring(math.floor(3.14))) -- expected: 3

-- bitwise operations
if bit then
request_handle:headers():add("compat_bit_band", tostring(bit.band(3, 1))) -- expected: 1
else
request_handle:headers():add("compat_bit_band", "not_supported")
end
end
```

This ensures that essential Lua functionalities remain stable across LuaJIT updates, preventing unexpected behavior in production environments where Lua filters are deployed.

[optional *Relevant Links*:]
>Any extra documentation required to understand the issue.