examples/l3fwd: modularize

examples/l3fwd: modularize

The main problem with l3fwd is that it is too monolithic with everything
being in one file, and the various options all controlled by compile time
flags. This means that it's hard to read and understand, and when making
any changes, you need to go to a lot of work to try and ensure you cover
all the code paths, since a compile of the app will not touch large parts
of the l3fwd codebase.

Following changes were done to fix the issues mentioned above

- Split out the various lpm and hash specific functionality into separate
  files, so that l3fwd code has one file for common code e.g. args
  processing, mempool creation, and then individual files for the various
  forwarding approaches.

  Following are new file lists
	  main.c (Common code for args processing, memppol creation, etc)
	  l3fwd_em.c (Hash/Exact match aka 'EM' functionality)
	  l3fwd_em_sse.h (SSE4_1 buffer optimizated 'EM' code)
	  l3fwd_lpm.c (Longest Prefix Match aka 'LPM' functionality)
	  l3fwd_lpm_sse.h (SSE4_1 buffer optimizated 'LPM' code)
	  l3fwd.h (Common include for 'EM' and 'LPM')

- The choosing of the lpm/hash path should be done at runtime, not
  compile time, via a command-line argument. This will ensure that
  both code paths get compiled in a single go

  Following examples show runtime options provided

  Select 'LPM' or 'EM' based on run time selection f.e.
                > l3fwd -c 0x1 -n 1 -- -p 0x1 -E ... (EM)
                > l3fwd -c 0x1 -n 1 -- -p 0x1 -L ... (LPM)
  Options "E" and "L" are mutualy-exclusive.
  If none selected, "L" is default.

Signed-off-by: Ravi Kerur <rkerur@gmail.com>
Signed-off-by: Piotr Azarewicz <piotrx.t.azarewicz@intel.com>
Tested-by: Tomasz Kulasek <tomaszx.kulasek@intel.com>
Acked-by: Tomasz Kulasek <tomaszx.kulasek@intel.com>
Acked-by: Konstantin Ananyev <konstantin.ananyev@intel.com>