Get String#crypt working with multi-ractor in cases where !HAVE_CRYPT_R

In commit 12f7ba5, ractor safety was added to String#crypt, however
in certain cases it can cause a deadlock. When we lock a native mutex,
we cannot allocate ruby objects because they might trigger GC which
starts a VM barrier. If the barrier is triggered and other native threads
are waiting on this mutex, they will not be able to be woken up in order to join
the barrier. To fix this, we don't allocate ruby objects when we hold the
lock.

The following could reproduce the problem:

```ruby
strings = []
10_000.times do |i|
  strings << "my string #{i}"
end

STRINGS = Ractor.make_shareable(strings)

rs = []
100.times do
  rs << Ractor.new do
    STRINGS.each do |s|
      s.dup.crypt(s.dup)
    end
  end
end
while rs.any?
  r, obj = Ractor.select(*rs)
  rs.delete(r)
end
```

I will not be adding tests because I am almost finished a PR to enable
running test-all test cases inside many ractors at once, which is how I
found the issue.

Co-authored-by: jhawthorn <john@hawthorn.email>

Author: 2 people

string.c

@@ -11262,8 +11262,15 @@ rb_str_crypt(VALUE str, VALUE salt)
         CRYPT_END();
         rb_syserr_fail(err, "crypt");
     }
-    result = rb_str_new_cstr(res);
+
+    size_t res_size = strlen(res)+1;
+    char *dup = malloc(res_size); // need to hold onto lock while duplicating a potentially static buffer
+    memcpy(dup, res, res_size);
     CRYPT_END();
+    // Don't allocate a ruby object while holding this lock, we could hit a VM barrier, which
+    // causes a deadlock if other ractors are waiting on this lock.
+    result = rb_str_new_cstr(dup);
+    free(dup);
     return result;
 }