Adjust top-level sections nodes to be administrative units

Previously we had gone back and forth on this because we couldn't come up with a solution that solved all of our issues.

Moving forward we are going to adjust all of the current top-level 'page' nodes to 'administrative units' this will allow us to post content into these groups and solve several UI issues. We will also update the corresponding group type views to include the top-level administrative unit content as well.

So for example there will now be a top-level student life (clubs) administrative unit. This will be the landing page when someone clicks on the "student life" link. The "Student Life News" block will now include the individual clubs announcements as well as any announcements in the top-level "Student Life" administrative unit.

Related
#1514862: Make it easier to add items to menus
#1516490: Add indication of group post belonging to on student life/academics/athletics

Related to this the create content block will need to change if we are in a top-level section I think the create content links should also include all of the related group type creation links.

jgraham: If we switch these to the admin units, can we make the admin user a member/manager of these on install?

@penguininja:3 Yes, will add it to the list of adjustments.

First round of this is committed in ee67fc5

Remaining is to subscribe the secondary user to these top-level nodes. To accomplish this I may need to re-order some of the install steps so that the secondary user is created prior to enabling the feature sets. I want to think about this a bit more as this also needs to be accounted for post-install as these nodes may/will change as users enable and disable the respective feature sets.

This makes me wonder if we should deprecate the "admin_unit" feature_set. Now it is only comprised of the admissions node since we now julio_administrative_unit is a dependency of the base install. Related to this discussion I think we should consider how the admissions node relates to #1516820: include parent/guardian feature set similar to admissions as it is just a node now.

Additional adjustments;
create content links
views add top-level admin units where they should be exclude them where they shouldn't be.

+1 on deprecating the Admin unit feature set. I think this should be part of the base install, as the site doesn't make sense without at least one group type. This is essentially core functionality at this point.

Assuming I'm not missing anything the remaining items are as follows;

1. adjust contexts to not display standard administrative unit blocks for the top-level sections, right now we get a lot of duplicate blocks due to contexts for 'administrative unit' and the corresponding sections both triggering with similar blocks. Related to this is #1516466: Contexts using paths as the adjustments will be similar switching away from the path based context to one based on the node id of the top-level pages.
2. Add the secondary user created on install as a group member. I'm working through a couple different ideas here, but I think the proper solution is to rework it so that whomever enables or disables a feature set is the node owner for those respective top-level nodes, right now it is hardcoded as uid 1. Then we just need to re-order the install process so that the secondary user is created before we choose the feature sets.

So the nodes are already created as the active user which is correct, we just needed to change that on install.

I think everything related to this issue has been addressed or is covered in other issues.