[lmi] Clang fixes

[Greg Chicares]

Here are some comments on
  https://github.com/vadz/lmi/pull/7/files
(the bulk of which I'm committing without comment).

  
https://github.com/vadz/lmi/pull/7/commits/4a87eab6bcf6222e6c2bd64644f4a48b219a443b
| Remove unused progress_meter::display_mode_ member
| This field is never used and resulted in clang -Wunused-private-field warning.

But it is used, e.g. in 'progress_meter_test.cpp'.

https://github.com/vadz/lmi/pull/7/commits/1951274d946f30d4796c1fa508e8c29544911b67
| Don't test whether unsigned variables are positive
| This is useless as the comparison can never be true

 void MultiDimAxisAnyChoice::SelectionChanged()
 {
     unsigned int const sel = GetSelection();
-    if(!(0 <= sel && sel < axis_.GetCardinality()))
+    if(sel >= axis_.GetCardinality())

Given:
  class MultiDimAxisAnyChoice
    :public  wxChoice
the member function GetSelection() must come from wxChoice:

http://docs.wxwidgets.org/trunk/classwx_choice.html#af13b41f102b0a819aead40919c5f4944
  virtual int wxChoice::GetSelection() const

so isn't assigning it to an 'unsigned int' the real error? Should we
instead change it the following way?
-    unsigned int const sel = GetSelection();
+    auto const sel = GetSelection();
(I'm not sure how to use 'const' with 'auto'.) Is 'unsigned int' an obvious
error, or might there have been some reason to choose that type? What happens
if GetSelection() returns wxNOT_FOUND?

https://github.com/vadz/lmi/pull/7/commits/7a8b165e9e813b01b6a8e9c18a6db9eb93ad0a91
| Add support for clang to configure

$ make check_concinnity
File 'configure.ac' contains reserved name '__clang__'.

Fixed.

https://github.com/vadz/lmi/pull/7/commits/1117856aea2c14506327ab2b7dfbe03d92ee527b
| Add extra braces to avoid a "possibly dangling else" warning

Okay. I didn't find any other instances of the same problem (Clang should
be able to do that better anyway). But I do see some code-smells, like
  if(...
  else if(...
  // no catch-all 'else' at the end
This is from libg++, which was declared obsolete in 1998. Shouldn't we use
gnu getopt instead? (Not boost::program_options, because we already have
too many dependencies on boost.)