Fix the following two gcc warnings:

elfio/elfio_section.hpp:50:36: warning: type qualifiers ignored on function return type [-Wignored-qualifiers]
     const size_t get_stream_size() const
                                    ^
elfio/elfio_segment.hpp:99:23: warning: type qualifiers ignored on function return type [-Wignored-qualifiers]
     get_stream_size() const

Crash 7d695153fd8052529d480c2352d4ada33a44bada

Fix crash 060833f08dc14d1712428742b3cad7af17b36bb7

Fix crash b82f05b0b25c8fdc98480e6d76b6d5f9164ae2bc

Running: crash-b82f05b0b25c8fdc98480e6d76b6d5f9164ae2bc
==2850==WARNING: AddressSanitizer failed to allocate 0x400000004000001 bytes
==2850==AddressSanitizer's allocator is terminating the process instead of returning 0
==2850==If you don't like this behavior set allocator_may_return_null=1
==2850==AddressSanitizer CHECK failed: /home/alvaro/tools/llvm/llvm/projects/compiler-rt/lib/sanitizer_common/sanitizer_allocator.cc:22
1 "((0)) != (0)" (0x0, 0x0)

Fix crash e3c41070342cf84dea077356ddbb8ebf4326a601

==12073==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x6110000003bb at pc 0x0000004c234c bp 0x7fcf6359ec30 sp 0x7fcf6359e3
e0
READ of size 11 at 0x6110000003bb thread T0
    #0 0x4c234b in __interceptor_strlen.part.30 /home/alvaro/tools/llvm/llvm/projects/compiler-rt/lib/asan/../sanitizer_common/sanitize
r_common_interceptors.inc:301
    #1 0x7165e6579d87 in std::char_traits<char>::length(char const*) /build/gcc-multilib/src/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3
/include/bits/char_traits.h:269
    #2 0x7165e6579d87 in std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(char const*, std
::allocator<char> const&) /build/gcc-multilib/src/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/basic_string.h:495
    #3 0x5c3333 in ELFIO::elfio::load_sections(std::istream&) /home/alvaro/fuzzers/elfio/ELFIO/examples/libfuzzer/../../elfio/elfio.hpp
:413:44

This will allow to perform some security checks when reading size values
from ELF file

Fix crash e1ce7cecf01cf800397a4302854d9d76fa19763c

The existing ELF file was somehow seriously broken.
It's now replaced with the file generated by the current code of
ELFio, which seems to be working correctly.

So the test now serves as a regression test for future
changes.

After loading, the data model in memory should resemble the original ELF file as closely as possible,
so that ELF viewers based on elfio will print out the original values, not the calculated ones.

Fix the following MSVC compiler warning:

elfio/elfio_note.hpp(77): warning C4267: 'initializing' : conversion from 'size_t' to 'ELFIO::Elf_Word', possible loss of data

by changing the type of max_name_sizei to Elf_Xword, as
note_secton->get_size() returns Elf_Xword and note_start_positions also
contains members of type Elf_Xword.

Don't cast away const qualifiers when accessing const data (e.g. section
data). This fixes the warnings such as the following when compiling with
GCC and the -Wcast-qual flag set:

warning: cast from type ‘const char*’ to type ‘ELFIO::Elf_Word* {aka unsigned int*}’ casts away qualifiers [-Wcast-qual]

There are discrepancies in documentations. SCO documentation
(http://www.sco.com/developers/gabi/latest/ch5.pheader.html#note_section)
requires 8 byte entries alignment for 64-bit ELF file,
but Oracle's definition uses the same structure
for 32-bit and 64-bit formats.
(https://docs.oracle.com/cd/E23824_01/html/819-0690/chapter6-18048.html)

It looks like EM_X86_64 Linux implementation is similar to Oracle's
definition. Therefore, the same alignment works for both formats

Previously, when assigning 'name' as a string, it's length was specified
using the full length of 'namesz'. However, this length includes the
trailing '\0' of the underlying char[]. This ultimately causes the C++
string that is created to (incorrectly) contain the '\0' character as
well. This leads to problems where e.g. the following will return false,
even when 'name' itself actually contains the string "GNU\0":

  if (name == "GNU") {
    return true;
  }
  return false;

To fix this, we should only include the length of the string minus the
trailing '\0'.