Improve type declaration

[Ragnar-Oock]

This PR is a follow-up to #257

Changes done in this PR :

• split Element in the various types that actually exist are run time (DataElement, Sequence, EncapsulatedPixelDataElement, FileMetaInformationElement)
• improve type for VR and tag parameters
• type Type Guard functions as such

Notes :

• The declaration for DataSet and ByteArrayParser has been more or less taken as is, I just updated the elements property and added missing JSDoc on .byteArray and .byteArrayParser.
• I added the JSDoc with my knowledge of the DICOM spec, how the lib tends to parse the files I throw at it, and some referencing to the code. Still, I can't guarantee the exactness of it and would appreciate it if someone with more knowledge took a look at it to validate.
• The VR enum is extracted from the table in DICOM Part 5 Section 6.2, I considered adding links to each VR's definition in this table but there is no id to anchor to in the page from NEMA.
• While I thought about updating the declaration for the various pixel data helper functions and some of the sequence reader functions to use the new Tag and narrowed down Element I decided against it as I don't have a good enough understanding of how they work and what kind of data they are actually expecting. This is thus something that can be further improved.

[Ragnar-Oock]

Come to think about it, the introduction of the Tag type might be a breaking change. Maybe should remove that.

[yagni]

@Ragnar-Oock Can I get push rights to your branch so we can collaborate on it?

[yagni]

Come to think about it, the introduction of the Tag type might be a breaking change. Maybe should remove that.

Can you give me an example of where it would break something?

[Ragnar-Oock]

If someone does something like :

const TAG_I_AM_INTERESTED_IN = 'x00200000'; //random tag, the actual value does not matter

const element = dataset.elements[TAG_I_AM_INTERESTED_IN];

They would get an error from TS saying that string can't be used to index type {[x: `x${string}`] : Element}.
And it doesn't add much anyway, so if you want to keep it maybe add it to the list of stuff to do in v2. Plus, the fact we can't limit the length of the string or the chars inside to be an actual 4 bytes hexadecimal value makes it a bit pointless.

A typescript playground demonstrating the problem

[Ragnar-Oock]

I thought about it a bit more.

While having the Tag type as it is now is a breaking change, it could be mitigated by changing it from :

type Tag = `x${string}`;

to

type Tag = `x${string}` | string;

That way it's possible to easily distinguish in the API what expects/returns a tag and what expects/returns just a string. And it's possible to have a doc string on it directly for intellisence to show to people that are not savvy of how the lib or the DICOM spec function (newcomers to a project using the lib mostly)

[Ragnar-Oock]

I'm not sure why the tests are failing, it says it can't install the ChromeDriver. Could someone look into that?

[yagni]

Yeah, please rebase onto yesterday's master--Circle CI's config needed updating per some changes the Chrome team made that broke things.

[Ragnar-Oock]

@yagni I just seen that you never accepted the invite for the collaborator access you've asked, I renewed the invite

[Ragnar-Oock]

I had to rename the branch in my fork to avoid issues with multiple parallel PR.
new PR : #278