Support TwinCAT solutions/project/source code files directly

[klauer]

blark will continue to support the current input formats - just without pytmc as a required dependency. I'm hoping to make file loading more easily customizable, with the option to load arbitrary file formats so long as you can provide an adapter (or a JSON-ified code block).

This is more of a TODO list at the moment - more details on the way soon.

Most of the following are at least somewhat done in the WIP branch wip_standalone_solution_parser:

• [x] Load .sln from TwinCAT
• [x] Iterate through tsproject files and PLCs
• [x] Find source code files
• [x] Make a blark-specific container for holding PLC source code of any format
• [ ] Make an adapter to take the loaded solution source code into the blark-specific containers
• [x] Map source code file lines onto "blark lines" (lines which will be fed into the grammar)
• [ ] Use source code file lines in linter output
• [x] Allow blark to write files back to TwinCAT formats without significantly changing the contents
• [x] Drop pytmc requirement; add lxml requirement
• [x] Remove all pytmc references
• [ ] Clean it all up and document it
• [ ] Make sure the test suite still runs
• [x] Update dependency store code to support this loader
• [ ] Remove dependency on deprecated distutils version parsing
• [x] Tweak blark CLI blark parse to work better with the generalized source code containers
• [ ] Rework blark CLI tool blark format entirely to either dump formatted code or rewrite in place
  • [ ] Consider the ability to convert any input type to any output type
  • [ ] Ensure all TwinCAT source code files support rewriting (property and others are still a TODO)

[klauer]

@engineerjoe440, as part of this refactor, I'm going to be changing the command-line interface of blark parse pretty significantly. The blark.parse*() methods will also be getting reworked.

Will this get in the way of your usage? If it does, will it be an issue to adapt your use case?

[engineerjoe440]

I don't think this should be too much of an issue. I suspect that I'll still be able to rework my tooling to derive from the refactoring changes you make. As long as the fundamental parsing is still possible, interface changes or function renames should not be a real issue. 👍

I'm excited to see how this all comes together, too! The tooling I've been working on is largely a linter for CODESYS-based systems, consuming the ST material from XML files, so there's some data-munging and manipulation that I have to do to get it correctly formatted for blark as it stands (nothing terrible, mind you!), so I'm excited to see what you're working on, specifically related to this remark:

Use source code file lines in linter output

Thank you, again, @klauer! I'm very excited about all of this!