correct String(array) docs

[stevengj]

I noticed that the String(::Vector{UInt8}) docs stated that String(array) always takes "ownership" of the data. This is no longer true in 0.7 except for arrays allocated with StringVector.

This PR corrects the String(array) docs to accurately describe the circumstances in which String takes ownership of the array (currently take! and read are the only documented ways as far as I can tell), and the fact that the length of the array is set to 0 in such cases.

Also, since String generally makes a copy for an arbitrary Vector{UInt8}, I saw no reason not to expand the constructor to accept AbstractVector{UInt8} (previously a MethodError). (Whoops, this method was already added.)

See also #24388 (comment)

[stevengj]

(I tend to think we should document StringVector too.)

[JeffBezanson]

This method already exists a few lines below.

[stevengj]

Whoops, I didn't notice that you already added that method; I removed the redundancy.

[nalimilan]

Thanks for documenting this. Though I must say that reading the description of the behavior, it doesn't feel satisfying. Apart from being inconsistent, it's dangerous because you can't know whether a vector passed by a caller has been allocated by e.g. read or not. So if you want to be safe, you need to make a copy, which most of the time will result in making two copies... That behavior doesn't seem to correspond to what was discussed at #24388, does it?

That said, better merge the PR since it describes what currently happens.

[StefanKarpinski]

cc @JeffBezanson

[JeffBezanson]

That behavior doesn't seem to correspond to what was discussed at #24388, does it?

That issue was about preventing mutation of strings via vectors, which the current behavior accomplishes.

[stevengj]

Resolved a merge conflict. Okay to merge?

[stevengj]

This PR is mostly obsolete, and now boils down to a 1-line clarification to the docs. Should be fine to merge.