support/testing: test_luvi: make luvi test reproducible

As explained by Jörg [1], iteration with pairs() does not result in the
same order since luajit 2.1.

From [2]
"Table iteration with pairs() does not result in the same order?

The order of table iteration is explicitly undefined by the Lua
language standard. Different Lua implementations or versions may use
different orders for otherwise identical tables. Different ways of
constructing a table may result in different orders, too. Due to
improved VM security, LuaJIT 2.1 may even use a different order on
separate VM invocations or when string keys are newly interned.

If your program relies on a deterministic order, it has a bug.
Rewrite it, so it doesn't rely on the key order.
Or sort the table keys, if you must."

Note: The "luvi -v" return 255 even on success.

[1] http://lists.busybox.net/pipermail/buildroot/2021-November/627938.html
[2] https://luajit.org/faq.html

Signed-off-by: Romain Naour <romain.naour@gmail.com>
Cc: Francois Perrad <francois.perrad@gadz.org>
Cc: Jörg Krause <joerg.krause@embedded.rocks>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>

support/testing/tests/package/test_luvi.py

@@ -25,11 +25,12 @@ class TestLuvi(infra.basetest.BRTest):
     def version_test(self):
         cmd = "luvi -v"
         output, exit_code = self.emulator.run(cmd)
-        self.assertIn('luvi', output[0])
-        self.assertIn('zlib', output[1])
+        output = sorted(output)
+        self.assertIn('libuv', output[0])
+        self.assertIn('luvi', output[1])
         self.assertIn('rex', output[2])
-        self.assertIn('libuv', output[3])
-        self.assertIn('ssl', output[4])
+        self.assertIn('ssl', output[3])
+        self.assertIn('zlib', output[4])
 
     def test_run(self):
         self.login()