Use STRING_PTR_RO, not STRING_PTR

[MichaelChirico]

Part of #6180, thanks to recommendation in R-exts

@item STRING_PTR 
@itemx DATAPTR       
@itemx STDVEC_DATAPTR
       Use @code{STRING_PTR_RO} and @code{DATAPTR_RO}. Obtaining
        writable pointers to these data can violate the memory manager's
        integrity assumptions and is not supported.

[MichaelChirico]

Actually this was not available in R 3.3.0, so we'll just use STRING_PTR() on really old R:

https://github.com/wch/r-source/blob/tags/R-3-3-0/src/include/Rinternals.h

It first got included in R 3.5.0:

r-devel/r-svn@cce3358
https://github.com/wch/r-source/blob/tags/R-3-5-0/src/include/Rinternals.h

[github-actions]

Generated via commit f14ec4b

Download link for the artifact containing the test results: ↓ atime-results.zip

Time taken to finish the standard R installation steps: 11 minutes and 20 seconds

Time taken to run atime::atime_pkg on the tests: 3 minutes and 19 seconds

[HughParsonage]

Actually this was not available in R 3.3.0, so we'll just use STRING_PTR() on really old R:

https://github.com/wch/r-source/blob/tags/R-3-3-0/src/include/Rinternals.h

It first got included in R 3.5.0:

r-devel/r-svn@cce3358 https://github.com/wch/r-source/blob/tags/R-3-5-0/src/include/Rinternals.h

I think this is fair. The objection to using this non-API call is because it would limit future changes to R, not because it was hazardous to use in past versions.