Update hdfwriter to include full filepath in root key in resource doc, add uuid DirectoryProvider for dynamic filenames

[jwlodek]

This PR does the following:

• Includes full filepath from the PandA hdf writer into the stream resource document. Before this the root key was hard coded to /
• Removes hard-coded period and device name in PandA writer filenames. I think if you want to include that in the name adding it to the passed in DirectoryProvider is a better solution.
• Adds a UUIDDirectoryProvider that generates dynamic filenames based on uuid4 - this is how we typically run things at NSLS-II.

[mrakitin]

We tested this addition at our lab with real PandA. All worked great!

[mrakitin]

A note to reviewers: this change was to exclude the mandatory PandA device name from the file name. If needed, this can be added via info.prefix at the device instantiation step.

[mrakitin]

The tests/linter issues need to be resolved, of course.

[DiamondJoseph]

This is handled slightly differently with the exisitng HDFFileWriter (passing the DirectoryInfo in whole), maybe allowing us to refactor the writer to use Path signals if #122 gets merged. It'd be good to settle on a common handling (not opposed to changing what's already in) or merging the implementations of HDFWriter, _HDFFile

I've added a comment to the PR this PR is merging into to the effect of uniting the handling.

[coretl]

@mrakitin why did you need to remove the PandA name from the HDF file path? We use the same DirectoryProvider in multiple detectors, so they need some level of uniqueness, hence the device name in the path.

An alternative would be to change the signature of DirectoryProvider so you would __call__ it with Device.name and a file extension, and it would make the whole Path for you...

[jwlodek]

I was going to include a DirectoryProvider that would append Device.name to the filename prefix with __call__ to this PR. Should I add that back in? My only hangup was what it should be called - I had originally used StaticDirectoryProviderWithDeviceName, but that seems quite a bit too long of a name. Either way, I think that is a cleaner solution than hard-coding the addition of the device name to the filename in the writer.

At NSLS-II we typically just use a UUID for the filename, which is inherently unique, so having a device name in the filepath is not necessary (see the UUIDDirectoryProvider) class included in this PR

[coretl]

I was going to include a DirectoryProvider that would append Device.name to the filename prefix with __call__ to this PR. Should I add that back in? My only hangup was what it should be called - I had originally used StaticDirectoryProviderWithDeviceName, but that seems quite a bit too long of a name.

Could pass an enum to the __init__ to specify the file naming behaviour? StaticDirectoryProvider("/tmp/files", FileNaming.UID)

[coretl]

@callumforrester @DiamondJoseph could we rename to FilePathProvider?

[DiamondJoseph]

I'm not precious about naming. There might be cause at this point to split FileNamer and DirectoryProvider into different things, with our implementation of FileNamer giving {beamline}-{name}_{data_collection} (even as I cling desperately to {prefix}{name}{suffix}) and NSLS can have a UUIDNameProvider while we share the StaticDirectoryProvider until we have need for our VisitDirectoryProvider sometime soon.