Split CodecID and ExtCodecID into separate fields

[g-maxime]

Fixes #249

[MarcosSueiro]

Thank you!! :-)

[JeromeMartinez]

@MarcosSueiro I think that I prefer to do as in MediaInfo, i.e. having only one field, which has the 2CC CodecID when it is not 0xFFFE, else the GUID from the WAVEFORMATEXTENSIBLE , e.g. 00000001-0000-0010-8000-00AA00389B71. In both CLI and GUI. 0xFFFE would be "hidden", but easy to recognize (GUID instead of 2CC in the CodecID field). Is it fine for you?

[MarcosSueiro]

@JeromeMartinez, in MediaInfo, I get

<CodecID>00000001-0000-0010-8000-00AA00389B71</CodecID> for a 0xFFFE file

and

<CodecID>1</CodecID> for a 0x0001 file.

Having a consistent, similar display in one field of BWFME in both CLI and GUI would be better.

I only wonder if others may find the numerical coding not so helpful in terms of finding documentation about the Codec.

As a comparison, exiftool shows

<RIFF:Encoding>Extensible</RIFF:Encoding> for a 0xFFFE file

and

<RIFF:Encoding>Microsoft PCM</RIFF:Encoding> for a 0x0001 file.

We do not have a strong preference as long as GUI and CLI are consistent.

Thank you!

[JeromeMartinez]

<RIFF:Encoding>Extensible</RIFF:Encoding> for a 0xFFFE file

Well, it is not enough, because if you have only that you don't have the real CodecID (the "extended" one), a file with 0xFFFE may also be "Microsoft PCM" (0000XXXX-0000-0010-8000-00AA00389B71 is for legacy mapping, so corresponds to XXXX, XXXX being 0001 in both, in the case of "Microsoft PCM") In practice, any long CodecID means "Extensible" in ExifTools.

Having a consistent, similar display in one field of BWFME in both CLI and GUI would be better.

@g-maxime, please adapt the PR for one field only, and full GUID (it is not so much used but in theory any byte of the GUID can be different).

[MarcosSueiro]

Sounds good @JeromeMartinez

[JeromeMartinez]

@MarcosSueiro you can check the latest development snapshot.