Don't allow invalid values to be set.

[brettfo]

This is a larger issue encompassing many smaller items, specifically, but not necessarily limited to:

• Instances of List<T> should be replaced with something like ListWithPredicate<T> that will throw on null or otherwise invalid values. This will make a lot of internal null checks go away. COMPLETE WITH c61c4636d0ab5eb7cabab276622d3dce36251c11
• Line type styles specified by entities will have to have a valid entry in the LTYPE table. If one is not present, one will be created. Similarly for other values. COMPLETE WITH 935580e28343985bfa484d317330c524fd7bb54d
• LEADERs and POLYLINEs require at least 2 vertices. COMPLETE FOR LEADER AND LWPOLYLINE WITH 905f3efcea1ec6bd4f84fc15b4fc873e529acee9 AND COMPLETE FOR POLYLINE WITH d1d39460be6ba5d4071ebd19e9875bbb9d53f512

During all of this, I'd like to follow the idea that this library will be able to open nearly any DXF file, valid or otherwise to avoid the situation that AutoCAD is in, namely that it's the most complete/correct implementation but it's rather fussy about what it will accept and easy to make crash.

[arendvw]

For the sanity checks on e.g. leaders and polylines, Rhino and RhinoCommon have the solution to add a IsValid method to each entity / kind of geometry. This allows for files to be read and written, but also allows the developers using this library to check themselves what to do with these potentially invalid cases.

The IsValid logic can be added / extended for each entity, e.g. having values to check if certain Radii in arcs are =< 360, or other sanity checks on geometry.

[brettfo]

My thinking for the last two items is something like this:

• Line types: When reading a file, don't worry if line types aren't specified; I still want to be able to read invalid files. When writing a file, if an entity specifies a line type that isn't in the table, add a default one so that the file on disk is valid. This would require an extra scan through the file on write, but I think I can shoehorn this into pointer resolution.

• LEADERs and POLYLINEs: I can get creative with ListWithPredicates and some internal visibility and a custom reader to allow reading an entity with < 2 vertices, but the public entry points would throw if the consumer tried to remove a vertex or clear the list. The constructors would also have to have the >= 2 restriction set. There is still the possibility that a LEADER with < 2 vertices could be read from disk and immediately written back out, but I don't think that's a problem that needs to be solved here.

[brettfo]

As a quick follow-up, I've fixed the line-type issue. The only remaining item for this issue is the LEADER and POLYLINE vertex counts.

[brettfo]

All cases mentioned by this issue should have now been addressed.