LPS-34035

Hi Brian, we have applied the changes to both places as you suggested.

```
I also don't think this needs to be its own method in GroupServiceImpl. 
I think it can just be a protected method inside StagingImpl. 
I don't think anyone else will call it. 
We definitely wouldn't need it as a JSON call for the UI.
```

We also wanted to keep all the logic in StagingImpl but we couldn't for one single reason: we need the companyId of the remote user and we don't have the remote user in StagingImpl (unless we make another call to obtain the remote user).

And now you may be wondering, why do you need the companyId of the remote user? this is the hard part....

Imagine we have this scenario:
LOCAL: CompanyA (adming: test@liferay.com)   |    
REMOTE: Company B (test@liferay.com) , Company C (test@liferay.com)

(Super admin has the same email address in all the companies)

Now, if you activate remote staging using virtualhost for a group from A to a group in B or C everything will be fine.
However, if you use the IP to identify the server, your group might be either in company B or company C. The remote user will be the one from B (by default, the user from the default company is chosen). If you try to activate remote staging in a group in another company then you will have a lot of corrupted data since the user company is not the same as the group company. 

So, in order to avoid this scenario, we are validating that the user doing the import in remote belongs to the same company as the group and we don't allow to activate staging if this is the case.

This was also explained with another example in the ticket: http://issues.liferay.com/browse/LPS-34035