Before this commit, many files are using std::string without including
<string>. It can work accidentally but causes issues when refactoring,
especially if using operator <<() which is included implicitly by some
compilers.

To find guilty header files, I used:

    grep -l "^ *std::string" $(grep -L "#include <string>" $(find . -type f -name "*.h"))

which finds all files containing "std::string" at the beginning of a line
(usually a member or variable declaration), but not "#include <string>".
And then this script to add the includes (plus some manual ediing):

    #!/usr/bin/env python3

    import re
    import argparse

    def fix_file(filename, header):

        with open(filename, "r") as f:
            content = f.read()

        matches = list(re.finditer(r"(#include .*\n)\n", content))
        if len(matches) == 0:
            print("no include!")
            sys.exit(-1)

        pos = matches[-1].end(1)
        open(filename, "w").write(content[:pos] + "#include <{}>\n".format(header) + content[pos:])

    if __name__ == "__main__":
        parser = argparse.ArgumentParser()
        parser.add_argument('--header', type=str, required=True)
        parser.add_argument('files', type=str, nargs='+')
        args = parser.parse_args()

        for filename in args.files:
            fix_file(filename, args.header)

find \( -name "*.hxx" -or -name "*.h" -or -name "*.cxx" \) -not -path "*ThirdParty*" -print0 | xargs -0 sed -sri "s/vcl_(algorithm|complex|cmath)\.h/\1/g"

find \( -name "*.hxx" -or -name "*.h" -or -name "*.cxx" \) -not -path "*ThirdParty*" -print0 | xargs -0 sed -sri "s/std::complex\.h/complex/g"

find \( -name "*.hxx" -or -name "*.h" -or -name "*.cxx" \) -not -path "*ThirdParty*" -print0 | xargs -0 sed -sri 's/#include "(algorithm|cmath|complex)"/#include <\1>/g'

find \( -name "*.hxx" -or -name "*.h" -or -name "*.cxx" \) -not -path "*ThirdParty*" -print0 | xargs -0 sed -sri "s/([^<])vcl_(adjacent_find|and|binary|binary_search|copy|copy_|count|count_if|equal|equal_range|fill|fill_n|find|find_end|find_first_of|find_if|for_each|generate|generate_n|generators_|heap|includes|inplace_merge|iter_swap|lexicographical_compare|lower_bound|make_heap|max|min|max_element|merge|merge_|min_element|mismatch|next_permutation|nth_element|partial_sort|partial_sort_copy|partition|stable_partition|partitions_|pop_heap|prev_permutation|push_heap|random_shuffle|remove|remove_copy|remove_copy_if|remove_if|replace|replace_copy|replace_copy_if|replace_if|reverse|reverse_copy|rotate|rotate_copy|search|search_n|set_difference|set_intersection|set_symmetric_difference|set_union|sort|sort_|sort_heap|stable_sort|swap|swap_|swap_ranges|transform|unique|unique_copy|upper_bound|bitset|abs|acos|asin|atan|atan2|ceil|cos|cosh|exp|fabs|floor|fmod|frexp|ldexp|log|log10|modf|pow|sin|sinh|sqrt|tan|tanh|complex|real|imag|arg|norm|conj|polar|jmp_buf|longjmp|sig_atomic_t|raise|signal|va_list|ptrdiff_t|size_t|FILE|fpos_t|fopen|fclose|feof|ferror|fflush|fgetc|fgetpos|fgets|fwrite|fread|fseek|ftell|perror|clearerr|rename|fputc|fputs|freopen|fsetpos|getc|getchar|gets|putc|putchar|puts|rewind|setbuf|setvbuf|tmpfile|tmpnam|ungetc|printf|sprintf|fprintf|vprintf|vsprintf|vfprintf)/\1std::\2/g"

find \( -name "*.hxx" -or -name "*.h" -or -name "*.cxx" \) -not -path "*ThirdParty*" -print0 | xargs -0 sed -sri "s/<<vcl_log/<<std::log/g"

This reverts commit 81bed5ae, reversing
changes made to f3749c05.

For now complex pixel types are not supported by Convert and DynamicConvert
applications (see switch/case in the generic DoExecute method). This commit just
document this limitation.

Note that the ExtractROI application can be used to convert image from/to
complex image.

The support of complex images in otb applications as improved in version
6.6. There is generic mechanism based on teh ClampImageFilter which allow to
go from/to complex or multi-bands scalar images.

The only change is to read the input image as ComplexFloatImageType which
support both complex image (single band) or image with 2 bands which corresponds
to the real and imaginary parts.

The documentation of the application has been updated to reflect this
modification.

OTB followed since the beginning the ITK convention and use .txx extension for all
template classes. Nevertheless, some development tools do not recognize .txx
file extension. Other tool like GitHub can't do in-browser syntax highlighting for
txx files I think.

The root problem is the use of the txx which should be changed to hxx (or hpp).

In 2011, after an in-depth discussion near April 20, 2011 on the
Insight-Developers mailing list, ITK rename all txx files to hxx (and event
prevent the push of .txx files with a pre-commit hook). It happens is major release v4.

You can find some arguments in the discussion about the change and also in other
projects related to ITK which applied the same modification, see for instance VXL:

https://github.com/vxl/vxl/issues/209

This commit apply now the same modification for OTB.

I understand that it will change some habit for developers and don't bring new
features but I think that in general it is better to stay align with ITK guidelines.

In my opinion, it always facilitate the use of OTB and ITK together if we share
when we can the same code architecture, directory organization, naming
conventions...

Add a rule to check if parameter key  and description are valid for QGIS
too. ApplicationEngine must enforce this rule and TestApplication must
include an additional test case. This can be done as part of refactoring
efforts in ApplicationEngine