Untangle some load order and mutual dependency issues between component loaders

BuddyPress's components are dependent upon each other in numerous ways. All
components depend in one way or another on bp-core. Many components reference
bp-members functions and globals. References to bp-xprofile can be found in
a number of components. And so on. We have managed to make these dependencies
work on a case-by-case basis, though the system becomes less stable as it
becomes more complex. The fact that all components are loaded at
bp_setup_components introduces the possibliity of numerous race conditions that
may not cause problems on vanilla installations of BuddyPress, but can cause
fatal errors when trying to customize in various ways.

As part of an ongoing project to disentangle and regularize these dependencies
(see eg #5750), this changeset introduces a few enhancements that make the
dependencies between components more predictable, more serialized, and more
stable.

- In bp-members and bp-groups, move canonical_stack determination out of the
  main setup_globals() method and into its own setup_canonical_stack() method.
  This new method runs after all components have had a chance to run
  setup_globals(). As a result, the components are able to reference each other
  safely when determining default and fallback components for redirects (for
  example, the members component has access to the activity component's slug
  and other global data when determining whether
  example.com/members/boone/activity/ should resolve to example.com/members/boone/)
- In bp-members, use only WP core data to set up the loggedin_user and
  displayed_user global objects. Previously, these objects were configured by
  referenced to xprofile, which required that xprofile be loaded before members.
  Now, users' display names are first loaded from wp_users, and are overridden
  by the xprofile component via filter, only after xprofile has fully
  initialized.
- In bp-xprofile, move the Settings > Profile navigation setup routine out of
  the main setup_nav() task. bp-xprofile loads early, before bp-settings has
  had a chance to set up its top-level navigation. As a result, bp-xprofile
  must wait until the bp_settings_setup_nav action to add its Profile subnav
  item.
- Fine-tune the component load order. bp-core, which acts more like a library
  of common functionality than like a traditional component, is moved from
  bp_setup_components:10 to bp_loaded:0. This ensures that it is available to
  all other components. bp-xprofile, which must load after bp-members but at
  the same time is closely coupled to it, is moved to bp_setup_components:2,
  just after bp-members.

These changes are enough to make it possible to move forward on dependent
tickets; see, for example, #5407. It's likely that significant entanglement
and load-order issues remain. We'll continue to fix them as they arise, by
making load order more explicit, and by breaking the component bootstrap
process into increasingly discrete chunks.

Fixes #5436

Props boonebgorges, r-a-y

git-svn-id: https://buddypress.svn.wordpress.org/trunk@8610 cdf35c40-ae34-48e0-9cc9-0c9da1808c22