New: Created parser for DFG (coscine/issues#921)

docs/ESLintConvention.md

-## ESLint Convention
-
-Make the changes to the code and tests and then commit to your branch. Be sure to follow the commit message conventions.
-
-Commit message summaries must follow this basic format:
-
-```
-Tag: Message (fixes #1234)
-```
-
-`Tag` should not be confused with git tag.
-`Message` should not be confused with git commit message.
-
-The `Tag` is one of the following:
-
-* `Fix` - for a bug fix.
-* `Update` - for a backwards-compatible enhancement.
-* `Breaking` - for a backwards-incompatible enhancement.
-* `Docs` - changes to documentation only.
-* `Build` - changes to build process only.
-* `New` - implemented a new feature.
-* `Upgrade` - for a dependency upgrade.
-
-The message summary should be a one-sentence description of the change. The issue number should be mentioned at the end. * The commit message should say "(fixes #1234)" at the end of the description if it closes out an existing issue (replace 1234 with the issue number). If the commit doesn't completely fix the issue, then use `(refs #1234)` instead of `(fixes #1234)`.
-
-Here are some good commit message summary examples:
-
-```
-Build: Update Travis to only test Node 0.10 (refs #734)
-Fix: Semi rule incorrectly flagging extra semicolon (fixes #840)
-Upgrade: Esprima to 1.2, switch to using Esprima comment attachment (fixes #730)
-```
-
-The commit message format is important because these messages are used to create a changelog for each release. The tag and issue number help to create more consistent and useful changelogs.
-
-Based on https://github.com/eslint/eslint.github.io/blob/master/docs/developer-guide/contributing.md#step-2-make-your-changes
-
-[npm-image]: https://badge.fury.io/js/conventional-changelog-eslint.svg
-[npm-url]: https://npmjs.org/package/conventional-changelog-eslint
-[travis-image]: https://travis-ci.org/stevemao/conventional-changelog-eslint.svg?branch=master
-[travis-url]: https://travis-ci.org/stevemao/conventional-changelog-eslint
-[daviddm-image]: https://david-dm.org/stevemao/conventional-changelog-eslint.svg?theme=shields.io
-[daviddm-url]: https://david-dm.org/stevemao/conventional-changelog-eslint
-[coveralls-image]: https://coveralls.io/repos/stevemao/conventional-changelog-eslint/badge.svg
-[coveralls-url]: https://coveralls.io/r/stevemao/conventional-changelog-eslint
\ No newline at end of file

docs/home.md

-## C# Template
-
-This template includes:
-
-* Automatic building using cake
-* Automatic testing with NUnit
-* Automatic linting with Resharper
-* Automatic documentation publishing using Gitlab CI / CD and a self written script which puts the docs in the docs folder to the wiki
-* Automatic releases using semantic-release ([ESLint Code Convention](ESLintConvention)), cake and Gitlab CI / CD
-
-## What you need to do
-
-Place you C# project solution file in .src/.
-Make sure Create directory for solution is unticked.
-
-![alt text](images/create_project.png "Create a new Project")
-
-Delete unused docs and update this README.
-
-Add [NUnit](nunit) tests to your solution.
-
-## Building
-
-Build this project by running either the build.ps1 or the build<span></span>.sh script.
-The project will be build and tested.
-
-### Links 
-
-*  [Commit convention](ESLintConvention)
-*  [Everything possible with markup](testdoc)
-*  [Adding NUnit tests](nunit)

docs/nunit.md

-## Add NUnit Tests
-
-### Add Nunit test adapter
-1.  Choose **Tools > Extensions and Updates**
-2.  In the **Extensions and Updates** dialog box, expand the **Online** category and then **Visual Studio Marketplace**. Then, choose **Tools > Testing**.
-2.  Select the **NUnit test adapter** and then choose **Download.**
-### Add Tests
-
-1.  Create a class library project and add it to your solution.
-
-    For convinience name it like your main project and add **.Tests** as a suffix.
-    ![alt text](images/create_class_library.png "Select Class Library")
-
-2.  Install the plug-in. In **Solution Explorer**, select the class library project, and then choose **Manage NuGet Packages** from its right-click or context menu.
-
-    ![alt text](images/add_a_package.png "Add a package")
-
-3.  In the **NuGet Package Manager** window, search for and select the plug-in (NUnit), and then choose **Install**.
-    ![alt text](images/select_framework.png "Select Project")
-
-    The framework is now referenced in your project under **References**.
-
-4.  From the class library project's **References** node, select **Add Reference**.
-
-    ![alt text](images/add_a_reference.png "Add a reference")
-
-5. In the **Reference Manager** dialog box, select the project that contains the code you'll test.
-
-    ![alt text](images/select_project.png "Select Project")
-
-6. Code your unit test.
-    
-    ![alt text](images/test_code.png "Test Code")

docs/testdoc.md

-It's very easy to make some words **bold** and other words *italic* with Markdown. You can even [link to Google!](http://google.com)
-
-Sometimes you want numbered lists:
-
-1. One
-2. Two
-3. Three
-
-Sometimes you want bullet points:
-
-* Start a line with a star
-* Profit!
-
-Alternatively,
-
-- Dashes work just as well
-- And if you have sub points, put two spaces before the dash or star:
-  - Like this
-  - And this
-
-If you want to embed images, this is how you do it:
-
-![Image of Yaktocat](https://octodex.github.com/images/yaktocat.png)
-
-# Structured documents
-
-Sometimes it's useful to have different levels of headings to structure your documents. Start lines with a `#` to create headings. Multiple `##` in a row denote smaller heading sizes.
-
-### This is a third-tier heading
-
-You can use one `#` all the way up to `######` six for different heading sizes.
-
-If you'd like to quote someone, use the > character before the line:
-
-> Coffee. The finest organic suspension ever devised... I beat the Borg with it.
-> - Captain Janeway
-
-[200~There are many different ways to style code with GitHub's markdown. If you have inline code blocks, wrap them in backticks: `var example = true`.  If you've got a longer block of code, you can indent with four spaces:
-
-    if (isAwesome){
-      return true
-    }
-
-GitHub also supports something called code fencing, which allows for multiple lines without indentation:
-
-```
-if (isAwesome){
-  return true
-}
-```
-
-And if you'd like to use syntax highlighting, include the language:
-
-```javascript
-if (isAwesome){
-  return true
-}
-```
-
-GitHub supports many extras in Markdown that help you reference and link to people. If you ever want to direct a comment at someone, you can prefix their name with an @ symbol: Hey @kneath — love your sweater!
-
-But I have to admit, tasks lists are my favorite:
-
-- [x] This is a complete item
-- [ ] This is an incomplete item
-
-When you include a task list in the first comment of an Issue, you will see a helpful progress bar in your list of issues. It works in Pull Requests, too!
-
-And, of course emoji!
-GitHub supports many extras in Markdown that help you reference and link to people. If you ever want to direct a comment at someone, you can prefix their name with an @ symbol: Hey @kneath — love your sweater!
-
-But I have to admit, tasks lists are my favorite:
-
- This is a complete item
- This is an incomplete item
-When you include a task list in the first comment of an Issue, you will see a helpful progress bar in your list of issues. It works in Pull Requests, too!
-
-And, of course emoji!