spaces_menu_access() does not handle group node edit

Once you apply #960318: Access to node/%node/edit controlled by OG instead of spaces and OG, you discover that spaces_menu_access() does not know how to handle editing group nodes. Why is that?

It turns out that group content types are supposed to be defined as part of a site space, (spaces[types][] = "site") so they are properly created outside of any group space. However, you want to view and edit them as part of a space. Unfortunately, because the feature defining the group content type is only enabled in the site space, the node's own group space throws access denied when you try to edit it, since it's a content type from a locally disabled feature.

The attached patch take the approach that if you are in a group space, you can View or Edit (but not create) any feature component defined by the groups feature that made the space possible. I.e., you are in a "group" group space in OpenAtrium, so all components of the atrium_group feature are editable and viewable within the space (barring other permissions).

I would have preferred to limit the change to only make editing the group node possible, but the only place to do that in Spaces/Spaces OG without nasty hacks comes in spaces_og.inc's access_feature(), and by that time you have lost any context except for the type of operation (create or view) and the name of the feature.

It would still have been nice to limit the change to editing whatever, and leave View behaviors untouched, but in the case of group nodes, og_menu_alter() steals the information from the menu_router that we are concerned with an update action.

We could still limit it, possibly to good affect, by putting a special case in spaces_menu_access() to look for og_menu_access_node_edit() as an access callback, and declare anything using that to be an update operation. Doing so would provide improved performance for Viewing features components, but come at the cost of a fairly explicit reference to spaces_og in spaces.module. I ended up opting not to do it (obviously) more for reasons of time invested in an uncertain patch than a judgement on technical merit.

I'll happily add that extra special casing in if that's where we want to go with it.

While this is only a Normal priority issue for now, once #960318: Access to node/%node/edit controlled by OG instead of spaces and OG lands this should be promoted to Major, as it will actively block group node edits.