Rename crypto/third_party/nss headers to avoid mixups.

Rename crypto/third_party/nss headers to avoid mixups.

When trying to include the real NSS headers from other files under
crypto/third_party/nss, the local versions would get used on the MSVS
build.

BUG=none
TEST=none


Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=110009

[wtc, 2011-11-14 07:59:44]

LGTM.

So using <blapi.h> or "blapi.h" doesn't matter?  I guess the
local version of a header has the highest precedence whether
<> or "" is used?

[mattm, 2011-11-15 00:17:33]

On 2011/11/14 07:59:44, wtc wrote:
> LGTM.
> 
> So using <blapi.h> or "blapi.h" doesn't matter?  I guess the
> local version of a header has the highest precedence whether
> <> or "" is used?

I think this is a difference in how MSVS handles include search order compared
to gcc/clang.  There are a few things that come into play:

1) our third_party copy of NSS maintains the original directory structure and
uses a bunch of /I flags to include each NSS dir (freebl, etc)

2) Our own includes of NSS use <> which don't use the current dir, but the
includes in the NSS headers use "". 

3) includes using "" check the current dir, then any previous dirs in the
include stack, then the /I dirs
(http://msdn.microsoft.com/en-us/library/36k2cdd4(v=VS.90).aspx)

So, our file includes an NSS file using <>, which then includes another NSS file
using "". Since the NSS headers are in different sub dirs, step 1 of the ""
include rules doesn't find the header, and step 2 goes back and searches in the
directory from the original include in our own code before doing step 3 with the
/I include paths which would find the real header.

gcc doesn't do step #2, and clang apparently doesn't either, though I couldn't
find docs for its search order.

[commit-bot: I haz the power, 2011-11-15 00:18:39]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/mattm@chromium.org/8538025/1

[commit-bot: I haz the power, 2011-11-15 01:36:47]

Change committed as 110009