Cache userdata after running WP_User_Query in BP_User_Query

WP_User_Query does not cache data that is stored in wp_users in a bulk fashion.
BP, on the other hand, does cache this data, as 'bp_core_userdata_' . $user_id.
This cached userdata is then referenced in many places throughout BP, including
the building of user_domains and userlinks. Thus, it can save up to 20 queries
per page (assuming per_page=20) during query loops.

A corresponding change has been made to the 'fields' parameter passed to
WP_User_Query from BP_User_Query. Because BP caches entire wp_users rows (see
BP_Core_User::get_core_userdata()), we must ensure that BP_User_Query is also
fetching entire rows. We opt not to use WP_User_Query's 'fields=all' parameter,
because it triggers the casting of WP_User objects, which in turn requires
expensive capability lookups.

See #5445

git-svn-id: https://buddypress.svn.wordpress.org/trunk@8024 cdf35c40-ae34-48e0-9cc9-0c9da1808c22
Set WP_User_Query 'fields' param correctly based on multisite vs non-MS

See r8024, #5445

git-svn-id: https://buddypress.svn.wordpress.org/trunk@8025 cdf35c40-ae34-48e0-9cc9-0c9da1808c22
POT, generated from r8025

git-svn-id: https://buddypress.svn.wordpress.org/trunk@8026 cdf35c40-ae34-48e0-9cc9-0c9da1808c22
Introduce bp_core_user_displaynames(), for quick, bulk displayname lookup

The technique BP uses for determining a user's displayname takes into
consideration whether the xprofile component is active, whether the user has a
WP display_name, and a number of other factors. Because the values are used so
often throughout BP, they are then cached in WP's object cache. However, there
are a number of places throughout BuddyPress where displaynames are fetched
in a way that is inconsistent with the "canonical" workflow (ie, by querying
the xprofile tables correctly). This causes inconsistent results, and also can
result in performance degradation when the persistent cache is skipped.
Moreover, the singular nature of bp_core_get_user_displayname() meant that
doing it the "right" way meant introducing large numbers of queries to a given
page load.

This changeset introduces bp_core_get_user_displaynames(), which contains all
the critical logic of bp_core_get_user_displayname() - including fallbacks for
various setups and support for the object cache - but allows for fetching large
numbers of displaynames without multiple queries. bp_core_get_user_displayname()
is now a wrapper for the more general function.

The function has been swapped in throughout BuddyPress as appropriate.

See #5445

git-svn-id: https://buddypress.svn.wordpress.org/trunk@8027 cdf35c40-ae34-48e0-9cc9-0c9da1808c22
Make sure all xprofile fields are saved in wp-admin/profile

Unlike front-end edit-fields screens, the wp-admin/profile displays all groups of fields on a single page. So the list of field ids is an array gathering for each group of fields a distinct comma separated list of ids. As a result, before using the wp_parse_id_list() function, we must ensure that these ids are merged into a single comma separated list.

Fixes #5425

git-svn-id: https://buddypress.svn.wordpress.org/trunk@8028 cdf35c40-ae34-48e0-9cc9-0c9da1808c22
POT, generated from r8028

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