Add a way to retrieve the standard-compliant namespace, fill "how to adopt" and "future evolution"

[rgommers]

All this is taken over from the array API standard, where the approach is now stable and the kinks have been worked out.

Closes gh-115
Closes gh-79

[MarcoGorelli]

Looks fine

to be able to define concat as a function, rather than as a dataframe method, could we also add something like a spec/API_specification/dataframe_api/namespace.py file in which to define functions such as concat?

[rgommers]

to be able to define concat as a function, rather than as a dataframe method, could we also add something like a spec/API_specification/dataframe_api/namespace.py file in which to define functions such as concat?

You can add content to __init__.py and list it in index.rst, like I did for null in gh-157. That should be simple enough I think; I suggest keeping it like that unless we are accumulating an unexpectedly large number of objects in the top-level namespace.

[rgommers]

This got two approvals and no unaddressed comments, so I'll hit the green button here.

[jorisvandenbossche]

In #115 (comment) you mentioned having this attribute on a non-compliant DataFrame object, as a way to go from that to a compliant one (unless I misunderstood the comment), which would not make this a fully correct check.

In general, this pathway seems missing in the current description? Assume you have written a function to work with a spec compliant dataframe API, is it then up to the user of your library to only pass such dataframes, or do we want a way that the function can check for any dataframe input if it can give in a compliant version of itself?

[rgommers]

Great catch, thanks Joris. We already have DataFrame.dataframe to get back out the user-facing/non-compliant one, but we indeed do need to add the conversion the other way.

Let me open a follow-up issue right now, since I won't get to fixing that up today.