bfd: have objcopy retain unknown ELF section flags

Silently zapping them is certainly wrong. When they're not replaced due
to user request, simply keeping them may not always be correct (we don't
know what such a flag means, after all), but is certainly at least
closer to having the output object still represent what the input object
had.

This introduces new binutils/ testsuite failures, but only for two
targets where most of the tests there fail anyway (amdgcn-elf and
nfp-elf), due to there not being an assembler available.

binutils/testsuite/binutils-all/copy-7.d

@@ -0,0 +1,14 @@
+#PROG: objcopy
+#readelf: -tW
+#name: copy with unknown section flag
+#warning: .*/copy-7[.].*:[.]special: warning: retaining .* 0x10000
+
+There are .* section headers, starting at offset .*
+
+Section Headers:
+  \[Nr\].*
+#...
+  \[ [1-9]\] .special
+       PROGBITS .*
+       \[0+10000\]: UNKNOWN \(0+10000\)
+#...

binutils/testsuite/binutils-all/copy-7.s

@@ -0,0 +1,7 @@
+	.globl text_symbol
+	.text
+text_symbol:
+	.nop
+
+	.section .special,"0x10000", %progbits
+	.long -1

binutils/testsuite/binutils-all/objcopy.exp

@@ -1313,6 +1313,7 @@ if [is_elf_format] {
     run_dump_test "group-7b"
     run_dump_test "group-7c"
     run_dump_test "copy-1"
+    run_dump_test "copy-7"
     run_dump_test "note-1"
     # Use copytest.o from the note-1 test to determine ELF32 or ELF64
     if [is_elf64 tmpdir/copytest.o] {