[emval] Prevent creating lvalue refs from thin air (#24606)

I'm having trouble reproducing this UB in isolation, but I ran into
issues with garbage values in test_i64_val while making other
innocent-looking changes. I think it might even explain the really weird
bug from
#24577 (comment)
that magically went away after a rebase despite no related changes being
made upstream.

Essentially, because I stupidly used `T&&` in a template, and because
it's [waves around] C++, it got inferred as `unsigned long long &`
instead of the desired `unsigned long long`, so in `.as<T>()` we were
quietly returning an `unsigned long long&` reference to a temporary
`unsigned long long` value on function stack.

Most of the time it somehow still works and, because it's templated,
it's not caught by Clang's "non-const lvalue reference to type"
diagnostic, but under unrelated changes and optimisations it can break
badly.

Author: RReverser

system/include/emscripten/val.h

@@ -570,6 +570,9 @@ class EMBIND_VISIBILITY_DEFAULT val {
 
   template<internal::EM_INVOKER_KIND Kind, typename Policy, typename Ret, typename... Args>
   static Ret internalCall(EM_VAL handle, const char *methodName, Args&&... args) {
+    static_assert(!std::is_lvalue_reference<Ret>::value,
+                  "Cannot create a lvalue reference out of a JS value.");
+
     using namespace internal;
 
     using RetWire = BindingType<Ret>::WireType;

test/embind/test_i64_val.cpp

@@ -34,7 +34,7 @@ string compare_a_64_js(T value) {
 }
 
 template <typename T>
-void test_value(T&& value) {
+void test_value(T value) {
   cout << "  testing value " << value << endl;
   cout << "    setting properties preserves the expected value" << endl;
   val::global().set("a", val(value));