[OMPIRBuilder] Avoid invalid debug location. (#151306)

This fixes #147063.

I tried to fix this issue in more general way in
https://github.com/llvm/llvm-project/pull/147091 but the reviewer
suggested to fix the locations which are causing this issue. So this is
a more targeted approach.

The `restoreIP` is frequently used in the `OMPIRBuilder` to change the
insert position. This function eventually calls
`SetInsertPoint(BasicBlock *TheBB, BasicBlock::iterator IP)`. This
function updates the insert point and the debug location. But if the
`IP` is pointing to the end of the `TheBB`, then the debug location is
not updated and we could have a mismatch between insert point and the
debug location.

The problem can occur in 2 different code patterns. 

This code below shows the first scenario.
```
  1. auto curPos = builder.saveIP();
  2. builder.restoreIP(/* some new pos */);
  3.  // generate some code
  4. builder.restoreIP(curPos);
```

If `curPos` points to the end of basic block, we could have a problem.
But it is easy one to handle as we have the location before hand and can
save the correct debug location before 2 and then restore it after 3.
This can be done either manually or using the `llvm::InsertPointGuard`
as shown below.

```
  // manual approach
  auto curPos = builder.saveIP();
  llvm::DebugLoc DbgLoc = builder.getCurrentDebugLocation();
  builder.restoreIP(/* some new pos */);
  // generate some code
  builder.SetCurrentDebugLocation(DbgLoc);
  builder.restoreIP(curPos);

  {
     // using InsertPointGuard
     llvm::InsertPointGuard IPG(builder);
     builder.restoreIP(/* some new pos */);
     // generate some code
  }
```
This PR fixes one problematic case using the manual approach.

For the 2nd scenario, look at the code below.

```
1. void fn(InsertPointTy allocIP, InsertPointTy codegenIP) {
2.   builder.setInsertPoint(allocIP);
3.   // generate some alloca
4.   builder.setInsertPoint(codegenIP);
5. }
```

The `fn` can be called from anywhere and we can't assume the debug
location of the builder is valid at the start of the function. So if 4
does not update the debug location because the `codegenIP` points at the
end of the block, the rest of the code can end up using the debug
location of the `allocaIP`. Unlike the first case, we don't have a debug
location that we can save before hand and restore afterwards.

The solution here is to use the location of the last instruction in that
block. I have added a wrapper function over `restoreIP` that could be
called for such cases. This PR uses it to fix one problematic case.