refactor: remove td-tools package

Author: danielpeintner

.gitignore

@@ -45,7 +45,6 @@ src/**/*.js
 
 # ignore private packages
 packages/*
-!packages/td-tools
 !packages/core
 !packages/binding-file
 !packages/binding-http

CONTRIBUTING.md

@@ -4,7 +4,7 @@ Thanks for your interest in this project. General information
 regarding source code management, builds, coding standards, and
 more can be found here:
 
--   https://projects.eclipse.org/projects/iot.thingweb/developer
+- https://projects.eclipse.org/projects/iot.thingweb/developer
 
 ## Legal Requirements
 
@@ -13,22 +13,22 @@ This process helps us in creating great open source software within a safe legal
 
 Thus, before your contribution can be accepted by the project team, contributors must electronically sign the [Eclipse Contributor Agreement (ECA)](http://www.eclipse.org/legal/ECA.php) and follow these preliminary steps:
 
--   Obtain an [Eclipse Foundation account](https://accounts.eclipse.org/)
-    -   Anyone who currently uses Eclipse Bugzilla or Gerrit systems already has one of those
-    -   Newcomers can [create a new account](https://accounts.eclipse.org/user/register?destination=user)
--   Add your GiHub username to your Eclipse Foundation account
-    -   ([Log into Eclipse](https://accounts.eclipse.org/))
-    -   Go to the _Edit Profile_ tab
-    -   Fill in the _GitHub ID_ under _Social Media Links_ and save
--   Sign the [Eclipse Contributor Agreement](http://www.eclipse.org/legal/ECA.php)
-    -   ([Log into Eclipse](https://accounts.eclipse.org/))
-    -   If the _Status_ entry _Eclipse Contributor Agreement_ has a green checkmark, the ECA is already signed
-    -   If not, go to the _Eclipse Contributor Agreement_ tab or follow the corresponding link under _Status_
-    -   Fill out the form and sign it electronically
--   Sign-off every commit using the same email address used for your Eclipse account
-    -   Set the Git user email address with `git config user.email "<your Eclipse account email>"`
-    -   Add the `-s` flag when you make the commit(s), e.g. `git commit -s -m "feat: add support for magic"`
--   Open a [Pull Request](https://github.com/eclipse-thingweb/node-wot/pulls)
+- Obtain an [Eclipse Foundation account](https://accounts.eclipse.org/)
+    - Anyone who currently uses Eclipse Bugzilla or Gerrit systems already has one of those
+    - Newcomers can [create a new account](https://accounts.eclipse.org/user/register?destination=user)
+- Add your GiHub username to your Eclipse Foundation account
+    - ([Log into Eclipse](https://accounts.eclipse.org/))
+    - Go to the _Edit Profile_ tab
+    - Fill in the _GitHub ID_ under _Social Media Links_ and save
+- Sign the [Eclipse Contributor Agreement](http://www.eclipse.org/legal/ECA.php)
+    - ([Log into Eclipse](https://accounts.eclipse.org/))
+    - If the _Status_ entry _Eclipse Contributor Agreement_ has a green checkmark, the ECA is already signed
+    - If not, go to the _Eclipse Contributor Agreement_ tab or follow the corresponding link under _Status_
+    - Fill out the form and sign it electronically
+- Sign-off every commit using the same email address used for your Eclipse account
+    - Set the Git user email address with `git config user.email "<your Eclipse account email>"`
+    - Add the `-s` flag when you make the commit(s), e.g. `git commit -s -m "feat: add support for magic"`
+- Open a [Pull Request](https://github.com/eclipse-thingweb/node-wot/pulls)
 
 For more information, please see the Eclipse Committer Handbook:
 https://www.eclipse.org/projects/handbook/#resources-commit
@@ -100,20 +100,20 @@ To reduce the size of the installation from about 800 MByte down to about 200 MB
 
 #### Troubleshooting
 
--   Build error about `No matching version found for @node-wot/...` or something about `match`
-    -   try `npm run unlock` from the project root before building
--   `sudo npm run link` does not work
-    -   try `npm run unlock` from the project root before calling `[sudo] npm run link`
-    -   try `npm link` in each package directory in this order: td-tools, core, binding-\*, cli, demo-servients
--   Error mesage for `npm link @node-wot/<module>`
-    `ELOOP: too many symbolic links encountered, stat '/usr/lib/node_modules/@node-wot/<module>`
+- Build error about `No matching version found for @node-wot/...` or something about `match`
+    - try `npm run unlock` from the project root before building
+- `sudo npm run link` does not work
+    - try `npm run unlock` from the project root before calling `[sudo] npm run link`
+    - try `npm link` in each package directory in this order: core, binding-\*, cli, demo-servients
+- Error mesage for `npm link @node-wot/<module>`
+  `ELOOP: too many symbolic links encountered, stat '/usr/lib/node_modules/@node-wot/<module>`
     1. Run `npm run link` in `thingweb.node-wot` again
     2. Remove `node_modules` in the targeted project
     3. Remove all `@node-wot/<module>` dependencies in your `package.json`
     4. Run `npm i` again
     5. Install the packages with `npm link @node-wot/<module>`
--   Build error around `prebuild: npm run bootstrap`
-    -   This has been seen failing on WSL. Try using a more recent Node.js version
+- Build error around `prebuild: npm run bootstrap`
+    - This has been seen failing on WSL. Try using a more recent Node.js version
 
 ## Adding a New Protocol Binding
 
@@ -205,28 +205,28 @@ Commit messages must be structured as follows:
 <footer>
 ```
 
--   `<type>`: A noun specifying the type of change, followed by a colon and a space. The types allowed are:
-    -   `feat`: A new feature
-    -   `fix`: A bug fix
-    -   `refactor`: Code change that neither fixes a bug or adds a feature (not relevant for end user)
-    -   `perf`: Change improves performance
-    -   `style`: Change does not affect the code (e.g., formatting, whitespaces)
-    -   `test`: Adding missing tests
-    -   `chore`: Change of build process or auxiliary tools
-    -   `docs`: Documentation only changes
--   `<scope>`: Optional. A term of free choice specifying the place of the commit change, enclosed in parentheses. Examples:
-    -   `feat(binding-coap): ...`
-    -   `fix(cli): ...`
-    -   `docs: ...` (no scope, as it is optional)
--   `<subject>`: A succinct description of the change, e.g., `add support for magic`
-    -   Use the imperative, present tense: "add", not "added" nor "adds"
-    -   Do not capitalize first letter: "add", not "Add"
-    -   No dot (.) at the end
--   `<body>`: Optional. Can include the motivation for the change and contrast this with previous behavior.
-    -   Just as in the subject, use the imperative, present tense: "change" not "changed" nor "changes"
--   `<footer>`: Optional. Can be used to automatically close GitHub Issues and to document breaking changes.
-    -   The prefix `BREAKING CHANGE: ` idicates API breakage (corresponding to a major version change) and everything after is a description what changed and what needs to be done to migrate
-    -   GitHub Issue controls such as `Fixes #123` or `Closes #4711` must come before a potential `BREAKING CHANGE: `.
+- `<type>`: A noun specifying the type of change, followed by a colon and a space. The types allowed are:
+    - `feat`: A new feature
+    - `fix`: A bug fix
+    - `refactor`: Code change that neither fixes a bug or adds a feature (not relevant for end user)
+    - `perf`: Change improves performance
+    - `style`: Change does not affect the code (e.g., formatting, whitespaces)
+    - `test`: Adding missing tests
+    - `chore`: Change of build process or auxiliary tools
+    - `docs`: Documentation only changes
+- `<scope>`: Optional. A term of free choice specifying the place of the commit change, enclosed in parentheses. Examples:
+    - `feat(binding-coap): ...`
+    - `fix(cli): ...`
+    - `docs: ...` (no scope, as it is optional)
+- `<subject>`: A succinct description of the change, e.g., `add support for magic`
+    - Use the imperative, present tense: "add", not "added" nor "adds"
+    - Do not capitalize first letter: "add", not "Add"
+    - No dot (.) at the end
+- `<body>`: Optional. Can include the motivation for the change and contrast this with previous behavior.
+    - Just as in the subject, use the imperative, present tense: "change" not "changed" nor "changes"
+- `<footer>`: Optional. Can be used to automatically close GitHub Issues and to document breaking changes.
+    - The prefix `BREAKING CHANGE: ` idicates API breakage (corresponding to a major version change) and everything after is a description what changed and what needs to be done to migrate
+    - GitHub Issue controls such as `Fixes #123` or `Closes #4711` must come before a potential `BREAKING CHANGE: `.
 
 Examples:
 
@@ -257,17 +257,17 @@ To avoid such warnings, please use `npm run lint` for linting your code and `npm
 
 ## Pull Requests and Feature Branches
 
--   Do not merge with master while developing a new feature or providing a fix in a new branch
--   Do a rebase if updates in the master such as a fix are required:
+- Do not merge with master while developing a new feature or providing a fix in a new branch
+- Do a rebase if updates in the master such as a fix are required:
 
 ```
 git checkout master && git pull && git checkout - && git rebase master
 ```
 
--   Pull Requests are merged using rebase
+- Pull Requests are merged using rebase
 
 ## Contact
 
 Contact the project developers via the project's "dev" list.
 
--   https://dev.eclipse.org/mailman/listinfo/thingweb-dev
+- https://dev.eclipse.org/mailman/listinfo/thingweb-dev