Fix warnings: option.c: makeset()/put_setnum(): Various (3): FP.

Problems   : Dereference of null pointer @ 6251.
             Dereference of null pointer @ 6267.
             Dereference of null pointer @ 6351.
Diagnostic : False positive.
Rationale  : Problems occur if varp is null after
             `varp = get_varp_scope(p, opt_flags);`.
             That can only happen if option is hidden. Those are options
             that can be set (for backwards compatibility reasons) but
             that do nothing (see `:h hidden-options`,
             `:h missing-options`). In particular, even if setting them
             is allowed, value is not stored, so these options have no
             real value.
             So, suggested error paths should not occur, as checks
             comparing option value and default value should discard
             them.
Resolution : We could just `assert(varp)` before line 6235
             `varp_local = varp;`. That was tried and worked.
             But we prefer modifying the code to explicitly skip hidden
             options.
             A redundant `!istermoption(p)` is removed too (it's already
             checked by for loop condition).
Fix warnings: syntax.c: get_id_list(): Double free: FP.

Problem    : Double free @ 5213.
Diagnostic : False positive.
Rationale  : I haven't been able to find the real reason why this is
             signaled. Nonetheless, I've been able to track down the
             introduction of this warning to commit
             77135447e09903b45d1482da45869946212f7904.
             The change there affecting this function is just a
             transformation maintaining semantics. So, this must be a
             FP, though I can't explain why.
Resolution : Revert changes in mentioned commmit touching this function.
Fix warnings: window.c: win_close_othertab(): Np dereference: FP.

Problem    : Dereference of null pointer @ 1980.
Diagnostic : False positive.
Rationale  : I haven't been able to find the real reason why this is
             signaled. Nonetheless, I've been able to track down the
             introduction of this warning to commit
             77135447e09903b45d1482da45869946212f7904.
             The change there affecting this function is just a
             transformation maintaining semantics. So, this must be a
             FP, though I can't explain why.
             Analyzer thinks `win->w_buffer` can be null in line 1980,
             following an error path assuming win->w_buffer null at line
             1819. Given that `win_close` function was not modified by
             mentioned commit, I don't understand why this path is
             analyzed after the changes, but not before them. Or if it's
             analyzed, why it's discarded before changes but not after
             them. I don't see anything in changes to
             `close_last_window_tabpage` that should affect to
             being able to deduce `win->w_buffer` is not null.
Resolution : Assert buffer not null in `win_close_othertab`.
             Function comments state that passed window should have a
             buffer that can be hidden, which implies there should be a
             buffer.
             Reverting changes to `close_last_window_tabpage` in
             mentioned commit would be another way to fix this (tried
             and worked).
             But assert is preferred in this case because flat style
             reads better and we have some other way to fix it.
Merge pull request #1698 from elmart/clang-analysis-fixes-6

Fix clang analysis warnings. (6)