Configuration File for TermSet validations

[mavaylon1]

Motivation

What was the reasoning behind this change? Please explain the changes briefly.

TLDR: Create a configuration file that sets which datatypes are associated with default NWB created termsets. This will be used for validation fields.

Note: This wrapping is done in the setter, requiring the field to be defined in the schema. If not, user the wrapper manually.
TODO:

• Rename TermSetConfigurator to TypeConfigurator
• Set the config file to use keys
• use ruamel and not yaml
• deep copy fix
• doc tutorial

How to test the behavior?

Show how to reproduce the new behavior (can be a bug fix or a new feature)

Checklist

• Did you update CHANGELOG.md with your changes?
• Does the PR clearly describe the problem and the solution?
• Have you reviewed our Contributing Guide?
• Does the PR use "Fix #XXX" notation to tell GitHub to close the relevant issue numbered XXX when the PR is merged?

[mavaylon1]

@oruebel Give a gander to the workflow above to see where my ideas are at.

[codecov]

Codecov Report

Attention: Patch coverage is 98.14815% with 2 lines in your changes missing coverage. Please review.

Project coverage is 88.65%. Comparing base (0000202) to head (0efd22b).
Report is 46 commits behind head on dev.

Files with missing lines	Patch %	Lines
src/hdmf/container.py	95.23%	1 Missing and 1 partial ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##              dev    #1016      +/-   ##
==========================================
+ Coverage   88.55%   88.65%   +0.10%     
==========================================
  Files          45       45              
  Lines        9616     9717     +101     
  Branches     2738     2760      +22     
==========================================
+ Hits         8515     8615     +100     
  Misses        778      778              
- Partials      323      324       +1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[rly]

@mavaylon1 At one of our recent meetings, we discussed not creating a global type config, but rather have a type config be associated with a particular type map, so that it is associated with whatever schema/namespaces are loaded at the moment. It looks like here, in the type map copy method, you pass the same type config around, so it is global instead. Can you change that?

[mavaylon1]

@mavaylon1 At one of our recent meetings, we discussed not creating a global type config, but rather have a type config be associated with a particular type map, so that it is associated with whatever schema/namespaces are loaded at the moment. It looks like here, in the type map copy method, you pass the same type config around, so it is global instead. Can you change that?

I must have misunderstood because I disagree. When we load a namespace, we are merging in the sense that the copy of the global type map can now navigate all namespaces. If a user wants to load a config that's unique to the namespace, they can call load and that too will be merged. That way I'm not searching for which config to use for which namespace. It's all under one.

My view is that the config file is associated with a namespace extension. Not the configurator.

Also if I get a copy of a the global type map. The type map that is used throughout hdmf, why would I have a config unique to that copy? That would imply I have to use that type map in other places. That's so much more difficult.

[rly]

Let's discuss whether the TypeConfigurator should be global or specific to an IO object in a separate PR.