[RFC] Fix clang analysis warnings. (1)

This is the first of a series of PR's aimed at taking the number of clang analysis warnings down to zero.

IMPORTANT: Commits contain links to online clang report entries, to ease review. I'm not sure if clang report generated links are deterministic. It that's not the case, then links would become stale on next report. So, if this can happen, please review this before merging other things into master (which would trigger a new clang report). UPDATE: Links are broken and won't be fixed. See below.

In principle, one warning is resolved in one commit (to match granularity of clang report and ease identification). But, when possible, warnings sharing a common cause/fix and belonging to the same function are grouped.

Following classification is used to describe warnings, after they have been resolved. 

Code | Type | Meaning
--------|-------------------|-------------
FP | False positive | Error condition cannot really occur, because of things we know, but the compiler doesn't. These are usually solved just asserting what the compiler needs to know.
MI | Multithreading issue | Error condition can be a real issue, but only under multithreading conditions. These are usually caused by use of global state and are usually solved by making local copies instead.
HI | Harmless issue | Error condition is in fact an issue, but a harmless one. These are usually solved removing/editing whatever is causing the warning.

`Code` is added as last part of commit messages to allow for a quick glimpse on diagnosed warning types without having to read full commit message.


This PR gets rid of **24** warnings in:
- curshor_shape.c
- screen.c
- ops.c
- regexp.c
- edit.c