MdeModulePkg/DxeCore: Avoid assertion in CoreLocateProtocol

MdeModulePkg/DxeCore: Avoid assertion in CoreLocateProtocol

The patch uses CoreAcquireLockOrFail() instead of
CoreAcquireProtocolLock() in CoreLocateProtocol() to avoid
assertion when CoreLocateProtocol() is called with the
protocol database locked.

The issue was found when changing PcdDebugPrintErrorLevel to
enable page/pool allocation debug message.
Nt32 platform hangs immediately after DxeCore is loaded.
Investigation shows the following calling stacks:

DxeCore entry point (Install a certain protocol)
0 DxeCore::CoreInstallProtocolInterface  // Protocol DB is locked
1 DxeCore::AllocatePool
2 PeiDxeDebugLibReportStatusCode::DebugPrint
3 DxeReportStatusCodeLib::ReportStatusCodeEx // <-------------------|
4 DxeReportStatusCodeLib::InternalGetReportStatusCode               |
5 DxeCore::LocateProtocol(StatusCodeRuntimeProtocol)                |
                     // Assertion when locking Protocol DB 2nd time |
6 DxeCore::CoreAcquireProtocolLock                                  |
7 PeiDxeDebugLibReportStatusCode::DebugAssert                       |
8 DxeReportStatusCodeLib::ReportSatusCodeEx  // loop begins ---------

In frame #6 the assertion is triggered due to the protocol database
is already locked. #8 calls #4 and the loop begins.
After changing #6 to CoreAcquireLockOrFail(), the assertion is
avoided and the loop is broken.

With the fix, NT32 can boot to Shell even setting
PcdDebugPrintErrorLevel to 0xFFFFFFFF, with all error levels turned
on.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>