Fix "Sorry, that site is reserved!" error when adding a site with slug same as your username.

[ideadude]

All Submissions:

• [x] Have you followed the Contributing guidelines?
• [x] Does your code follow the WordPress' coding standards?
• [x] Have you checked to ensure there aren't other open Pull Requests for the same update/change?

Changes proposed in this Pull Request:

The wpmu_validate_blog_signup() function can take a 3rd parameter for the user adding the site. This is used, among other things, to make sure users don't create sites with slugs equal to existing usernames UNLESS they are that user.

Our pmpron_checkSiteName() function now passes the current_user into the wpmu_validate_blog_signup() call so users can create sites with their own username.

How to test the changes in this Pull Request:

1. Have site credits. Visit the manage sites page.
2. Add a site with a slug the same as the current user's username. (You may have to delete a site -carefully- if it already exists.)
3. The site should be added after applying this patch. Before, it would throw an error.

Other information:

IMPORTANT NOTE: This issues brings up a related question, which is "why wasn't this error happening if a user chose a sitename same as their username at checkout?" I think the answer is that we aren't doing the wpmu_validate_blog_signup() check at checkout. We should test and look into calling our pmpron_checkSiteName() before creating sites at checkout.

• [x] Have you added an explanation of what your changes do and why you'd like us to include them?
• [x] Have you successfully run tests with your changes locally?

Changelog entry

BUG FIX: Fixed "Sorry, that site is reserved!" error when adding a site with slug same as your username.

[ideadude]

Just following up to confirm that we do check the site name during checkout (https://github.com/strangerstudios/pmpro-network/blob/dev/pmpro-network.php#L457-L463), however if a brand new user is checking out their username is not in the DB yet and so the check wasn't failing there. It would have failed for logged in users. It won't fail now with this PR applied.

So bottom line is I think this PR is enough to address this issue.