acinclude: Strip out -mno-avx512f provided by DPDK.

acinclude: Strip out -mno-avx512f provided by DPDK.

DPDK forces '-mno-avx512f' flag for the application if the toolchain
used to build DPDK had broken AVX512 support.  But OVS could be built
with a completely different or fixed toolchain with correct avx512
support.  In this case OVS will detect that toolchain is good and will
try to build AVX512-optimized classifier.  However, '-mno-avx512f'
flag will be passed from the DPDK side breaking the build:

  In file included from /gcc/x86_64-linux-gnu/8/include/immintrin.h:55,
                 from /gcc/x86_64-linux-gnu/8/include/x86intrin.h:48,
                 from /dpdk/../x86_64-linux-gnu/dpdk/rte_vect.h:28,
                 from /dpdk/../x86_64-linux-gnu/dpdk/rte_memcpy.h:17,
                 from /dpdk/rte_mempool.h:51,
                 from /dpdk/rte_mbuf.h:38,
                 from ../lib/dp-packet.h:25,
                 from ../lib/dpif.h:380,
                 from ../lib/dpif-netdev.h:23,
                 from ../lib/dpif-netdev-lookup-avx512-gather.c:22:
  /usr/lib/gcc/x86_64-linux-gnu/8/include/avx512bwintrin.h:413:1: error:
     inlining failed in call to always_inline '_mm512_sad_epu8':
     target specific option mismatch
   _mm512_sad_epu8 (__m512i __A, __m512i __B)

Fix that by stripping out `-mno-avx512f` as we already do for '-march'.
This will allow the OVS to decide if the AVX512 can be used.

Reordering of CFLAGS (i.e. adding DPDK flags before OVS ones) is not an
option since autotools might reorder them back later and it's very
unpredictable.

Reported-at: https://github.com/openvswitch/ovs-issues/issues/201
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Acked-by: Harry van Haaren <harry.van.haaren@intel.com>
Signed-off-by: Ian Stokes <ian.stokes@intel.com>