Support read with classes using REGISTER_SUBCLASS_WITH_TYPENAME

[oruebel]

This is a follow-up issue to #91, #85 . Currently for classes that use REGISTER_SUBCLASS_WITH_TYPENAME can be used to create a new NWB file, but are not automatically used when reading from a file. This is because these classes do not have a corresponding neurodata_type in the schema, and the logic for detecting the type to use is purely based on neurodata_type right now. See:

aqnwb/docs/pages/devdocs/registered_types.dox

Lines 67 to 80 in bfa740a

	* A special version of the ``REGISTER_SUBCLASS`` macro, called ``REGISTER_SUBCLASS_WITH_TYPENAME``,
	* allows setting the typename explicitly as a third argument. This is for the **special case**
	* where we want to implement a class for a modified type that does not have its
	* own `neurodata_type` in the NWB schema. An example is `ElectrodesTable` in NWB <v2.7, which
	* did not have an assigned `neurodata_type`, but was implemented as a regular
	* `DynamicTable`. To allow us to define a class `ElectrodeTable` to help with writing the table
	* we can then use ``REGISTER_SUBCLASS_WITH_TYPENAME(ElectrodeTable, "core", "DynamicTable")``
	* in the `ElectrodesTable` class. This ensures that the `neurodata_type` attribute is set
	* correctly to `DynamicTable` on write instead of `ElectrodesTable`. However, on read this
	* will by default not use the `ElectrodesTable` class but the regular `DynamicTable` class
	* since that is what the schema is indicating to use. In the registry, the class will still
	* be registered under the ``core::ElectrodesTable`` key, but with "DynamicTable" as the
	* typename value and the `ElectrodesTable.getTypeName` automatic override returning
	* the indicated typename instead of the classname.

Possible solutions:

• ElectrodeTable (which is currently the main case for this), is planned to get a neurodata_type assigned at some point. We can wait for that schema change and update ElectrodeTable then. However, this does not fix the more general user-case/problem.
• We could: 1) extend REGISTER_SUBCLASS_WITH_TYPENAME to support specifying a fixed path, 2) update RegisteredType::create to also consider the path when deciding on the class to use, 3) update the registry in RegisteredType to support storing and looking up types with an additional optional path