Re-enable windows builds

[h-vetinari]

This is essentially a rebase of #81, though the bot tried windows in #83 as well, where it failed with

D:/bld/r-arrow_1721257668194/_h_env/lib/R/include\Rinternals.h:34:11: fatal error: 'cstdio' file not found
   34 | # include <cstdio>
      |           ^~~~~~~~

---

update: due to apache/arrow#43398 & r-lib/cpp11#360

Closes #81
Closes #79

[conda-forge-webservices]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe/meta.yaml) and found it was in an excellent condition.

[h-vetinari]

Interestingly, after conda-forge/r_clang_activation-feedstock#7, it seems we are finding the STL again, but the run into:

In file included from altrep.cpp:18:
In file included from .\./arrow_types.h:22:
In file included from .\.\./arrow_cpp11.h:20:
In file included from C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Tools\MSVC\14.40.33807\include\memory:14:
In file included from C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Tools\MSVC\14.40.33807\include\xmemory:15:
C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Tools\MSVC\14.40.33807\include\xutility:1408:13: error: object of type 'cpp11::writable::r_vector<double>::iterator' cannot be assigned because its copy assignment operator is implicitly deleted
 1408 |         _It = _STD forward<_UIter>(_UIt);
      |             ^

This is with

     m2-zip:             3.0.3-hd8ed1ab_4          conda-forge
     pcre2:              10.44-h3d7b363_0          conda-forge
     pkg-config:         0.29.2-h88c491f_1009      conda-forge
-    r_clang_win-64:     18.1.5-h57928b3_0         conda-forge
+    r_clang_win-64:     18.1.8-h57928b3_0         conda-forge
     ucrt:               10.0.22621.0-h57928b3_0   conda-forge
     vc:                 14.3-h8a93ad2_20          conda-forge
     vc14_runtime:       14.40.33810-ha82c5b3_20   conda-forge
     vs2015_runtime:     14.40.33810-h3bf8584_20   conda-forge
-    vs2022_win-64:      19.38.33130-h0bfb142_18   conda-forge
-    vs_win-64:          2022.8-h0bfb142_18        conda-forge
+    vs2022_win-64:      19.40.33808-h753ab0a_20   conda-forge
+    vs_win-64:          2022.10-h753ab0a_20       conda-forge
     vswhere:            3.1.7-h57928b3_0          conda-forge
     zstd:               1.5.6-h0ea2cb4_0          conda-forge

so presumably we needed a rebuild of clang_win-64 matching the VC components in the azure image.

[xhochy]

The new error could simply stem from the fact that clang is more strict on Windows than MinGW/MSVC (or clang in any other setting). We probably need to fix some of the arrow code.

[h-vetinari]

Holy macaroni, I had no idea that the last available builds before r_clang_win-64 18.x would be 11.0. That opens up a large surface of where the error might be at. However, playing around with the godbolt link that the arrow dev's provided in the issue I raised upstream, even clang 11 isn't permissive enough to build the code in question.