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'.

This change makes it possible to use the regular API to build up
elf files which include the file header.

The old implementation aligned the segment start. However, the
intended behaviour is to align the offset and the vaddr
(p_vaddr % p_align == p_offset % p_align). This is required for the
loader which can then operate on memory pages.

this is probably not required but definitely does not hurt

Conflicts:
	elf_examples/asm_copy

Only elf files with strange GNU_RELRO segments fail the load, save, cycle.

It would maybe a good idea to separate the layout functionality from the
current save. The current coupling of layout and save make it
impossible to build layouts which contain the elf header via the public
API.

Many example elfs (hello_32, hello_64, asm ...) require that the
first section directly follows the program header table. The
section header is then placed between segments or at the end.

This change prepares the late placement of section header table.

The fact that segments can contain header information as well as
sections requires that sections within segments are emitted first.

The initial implementation only made sure that all sections and segments
are properly aligned. This is enough for simple embedded applications
but can not deal with more complex layouts.

The new implementation should be more generic given that it respects the
virtual addresses of the individual sections.

One thing which is currently not supported by this rewrite are segments
which contain the program/segment header or even the whole elf header.

ALLOC sections are now matched against the virtual address space of
the segment. Non ALLOC sections still use the offset approach.