[lmi] Fixing build with clang 7 and 64-bit Linux

[Vadim Zeitlin]

 Hello,

 I wanted to build lmi with clang to test some changes and it turns out
there are quite a few of new errors and warnings (which, of course, are
also fatal due to the use of -Werror) due to the changes done since the
last time I tested clang build (which must have been a couple of months
ago, apparently).

 I've fixed those of them which seemed straightforward to me, but for a
couple of them I'm not sure about what would you prefer to do for them,
here is the full list of the remaining problems from "make -k" output:

---------------------------------- >8 --------------------------------------
In file included from input_sequence_parser.cpp:24:
input_sequence_parser.hpp:107:9: error: private field 'inforce_duration_' is 
not used [-Werror,-Wunused-private-field]
    int inforce_duration_;
        ^
input_sequence_parser.hpp:108:9: error: private field 'effective_year_' is not 
used [-Werror,-Wunused-private-field]
    int effective_year_;
        ^
2 errors generated.
make[1]: *** [Makefile:6887: liblmi_la-input_sequence_parser.lo] Error 1
  CXX      lmi_wx-main_wx.o
input_sequence.cpp:142:26: error: non-constant-expression cannot be narrowed 
from type 'lmi::ssize_t' (aka 'long') to 'int' in initializer list 
[-Wc++11-narrowing]
    :years_to_maturity_ {lmi::ssize(v)}
                         ^~~~~~~~~~~~~
input_sequence.cpp:142:26: note: insert an explicit cast to silence this issue
    :years_to_maturity_ {lmi::ssize(v)}
                         ^~~~~~~~~~~~~
                         static_cast<int>( )
input_sequence.cpp:165:26: error: non-constant-expression cannot be narrowed 
from type 'lmi::ssize_t' (aka 'long') to 'int' in initializer list 
[-Wc++11-narrowing]
    :years_to_maturity_ {lmi::ssize(v)}
                         ^~~~~~~~~~~~~
input_sequence.cpp:165:26: note: insert an explicit cast to silence this issue
    :years_to_maturity_ {lmi::ssize(v)}
                         ^~~~~~~~~~~~~
                         static_cast<int>( )
  CXX      libskeleton_la-about_dialog.lo
2 errors generated.
make[1]: *** [Makefile:6873: liblmi_la-input_sequence.lo] Error 1
census_view.cpp:1656:24: error: no matching function for call to 'min'
    int const newsel = std::min
                       ^~~~~~~~
/usr/bin/../lib/gcc/x86_64-linux-gnu/8/../../../../include/c++/8/bits/algorithmfwd.h:383:5:
 note: candidate template ignored: deduced conflicting types for parameter 
'_Tp' ('int' vs. 'long')
    min(const _Tp&, const _Tp&);
    ^
/usr/bin/../lib/gcc/x86_64-linux-gnu/8/../../../../include/c++/8/bits/stl_algo.h:3456:5:
 note: candidate template ignored: could not match 
'initializer_list<type-parameter-0-0>' against 'int'
    min(initializer_list<_Tp> __l, _Compare __comp)
    ^
/usr/bin/../lib/gcc/x86_64-linux-gnu/8/../../../../include/c++/8/bits/algorithmfwd.h:388:5:
 note: candidate function template not viable: requires 3 arguments, but 2 were 
provided
    min(const _Tp&, const _Tp&, _Compare);
    ^
/usr/bin/../lib/gcc/x86_64-linux-gnu/8/../../../../include/c++/8/bits/stl_algo.h:3450:5:
 note: candidate function template not viable: requires single argument '__l', 
but 2 arguments were provided
    min(initializer_list<_Tp> __l)
    ^
1 error generated.
make[1]: *** [Makefile:7209: libskeleton_la-census_view.lo] Error 1
---------------------------------- >8 --------------------------------------

 The first two errors, about the unused private fields, actually do also
look straightforward to me and I'd just remove these member variables as
well as the corresponding SequenceParser ctor arguments. But, AFAIR, the
last time this warning came up, you preferred to suppress it rather than
remove the unused fields. Do you think that these variables also need to
be preserved or could I remove them?

 As for the rest of the errors, they're all due to lmi::ssize() returning
ssize_t (a.k.a. long) and not int, and so are due to building on a 64-bit
Linux system rather than using clang. Strangely enough, gcc8 doesn't mind
initializing int fields with long values, even though I think this should
be forbidden when using C++11 initialization. But it gives the same error
about min() ambiguity as well (just with a much longer error message). So
IMO the solution to them is to make ssize() return int, as was previously
discussed in e.g. the beginning of this message:

        http://lists.nongnu.org/archive/html/lmi/2018-08/msg00031.html

So the question is whether I could make this change or if you'd prefer to
do it yourself, in which case I'll have to temporarily abandon my efforts
to fix clang build? I'd prefer to fix it and, ideally, set CI build up on
GitHub, so that both clang and gcc (and maybe even MSVS?) builds could be
automatically tested all the time but it's, of course, not very urgent.

 Please let me know what do you think,
VZ