[Clean up] Fix the comment for SiteIntance::CreateForURL

[Clean up] Fix the comment for SiteIntance::CreateForURL

In SiteIntance::CreateForURL there will certainly create a new SiteInstance
and BrowsingIntance since in this new BrowsingIntance we will not find any
existing SiteIntance. So BrowsingIntance will never be deleted even beyond
the scope of the method.
The original comments will make some confusion.

BUG=11629
Committed: https://crrev.com/9f9a53536cd585291f4a63f8a789fa64612dc73a
Cr-Commit-Position: refs/heads/master@{#315308}

[jinlong.zhai, 2015-02-06 08:56:39]

jinlong.zhai@samsung.com changed reviewers:
+ davidben@chromium.org, nasko@chromium.org

[jinlong.zhai, 2015-02-06 08:56:40]

Please help to look at the nits.
Thanks

[Charlie Reis, 2015-02-06 19:09:33]

creis@chromium.org changed reviewers:
+ creis@chromium.org

[Charlie Reis, 2015-02-06 19:09:34]

It helps to do some digging through past revisions to understand this, but I
think this change is correct.  (Here, I used the git blame feature in
cs.chromium.org to dig up the reasons for the original code.)

The old comment was introduced in https://codereview.chromium.org/115110, and it
was correct at the time.  We treat some sites as one-process-per-site, so that
all instances of things like chrome://settings will end up in the same process. 
In the past, we implemented that by returning an existing SiteInstance from a
new BrowsingInstance.

I later refactored that in https://chromiumcodereview.appspot.com/10575014 for
https://crbug.com/11629.  We now have different SiteInstances in each
BrowsingInstance, but they can be grouped together in RenderProcessHost.

In other words, it's a bit subtle, but this update to the comment is correct for
how the code currently works.  LGTM.

[Charlie Reis, 2015-02-06 19:10:39]

I updated the bug number of the CL to 11629 so that we can track the cleanup,
and I'll go ahead and commit this.

[Charlie Reis, 2015-02-06 19:11:01]

The CQ bit was checked by creis@chromium.org

[Charlie Reis, 2015-02-06 19:12:01]

The CQ bit was unchecked by creis@chromium.org

[Charlie Reis, 2015-02-06 19:14:39]

The CQ bit was checked by creis@chromium.org

[commit-bot: I haz the power, 2015-02-06 19:14:55]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/880303004/1

[commit-bot: I haz the power, 2015-02-06 19:21:02]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2015-02-06 19:21:02]

Try jobs failed on following builders:
  chromium_presubmit on tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromium_presub...)

[Charlie Reis, 2015-02-06 19:36:39]

Looks like you're not listed in the authors file:

http://build.chromium.org/p/tryserver.chromium.linux/builders/chromium_presub...

** Presubmit Warnings **
jinlong.zhai@samsung.com is not in AUTHORS file. If you are a new contributor,
please visit
http://www.chromium.org/developers/contributing-code and read the "Legal"
section
If you are a chromite, verify the contributor signed the CLA.

[jinlong.zhai, 2015-02-09 03:07:55]

Now I have listed in the authors file, since my first patch have been merged
(https://codereview.chromium.org/889313003).
So please help to re-trigger this patch.

[nasko, 2015-02-09 14:59:38]

The CQ bit was checked by nasko@chromium.org

[commit-bot: I haz the power, 2015-02-09 15:00:28]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/880303004/1

[commit-bot: I haz the power, 2015-02-09 15:54:39]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2015-02-09 15:55:05]

Patchset 1 (id:??) landed as
https://crrev.com/9f9a53536cd585291f4a63f8a789fa64612dc73a
Cr-Commit-Position: refs/heads/master@{#315308}