Move ProbeInterface configurations from Bonsai file to JSON files

[bparks13]

This PR is a new effort to address #366.

This is not yet finished, but I have completed the work for Neuropixels 1.0 devices (NeuropixelsV1e / NeuropixelsV1f) so that we can discuss the logic and the implementation.

The major work centers around the NeuropixelsV1ProbeConfiguration class; most properties that used to be in the device node have been moved to the configuration class, since this is the most efficient way to consolidate information. I also added a ProbeInterfaceFileName property to the configuration, which is where the ProbeInterface configuration will be saved.

Another major change is how the ProbeGroup class is initialized. Previously it was initialized during loading, but with the addition of the ProbeInterface file this led to issues. It is very easy for the filename to be set, but then the file be renamed or moved; this means that during loading there would be an exception thrown since the file doesn't exist, preventing the user from being able to successfully open the file. Therefore, now the ProbeGroup property has deferred loading, waiting for the first time the getter is called. This has the added benefit of fitting in with the Bonsai pattern where loading is deferred, allowing the filename to be modified via command line without issue, since the other way it could throw an exception during loading.

The JSON files are only saved when the Bonsai file is saved, to prevent any desynchronization.

Note: Prior to modifying Neuropixels V2 to follow this pattern, this branch should contain the changes made in #493. There are significant changes made in that PR that would make merge conflicts incredibly nasty to untangle.

[bparks13]

@aacuevas I've implemented what we discussed today. The only thing that I am a little unsure about is line 361 here:

bonsai-onix1/OpenEphys.Onix1/NeuropixelsV1ProbeConfiguration.cs

Lines 355 to 363 in a43719b

	try
	{
	probeGroup = probeGroupTask?.Result ?? new NeuropixelsV1eProbeGroup();
	}
	catch (AggregateException ae)
	{
	probeGroup = new();
	throw new InvalidOperationException($"There was an error loading the ProbeInterface file, loading the default configuration instead.\n\nError: {ae.InnerException.Message}", ae.InnerException);
	}

Without this call to new(), the user would be stuck in an infinite loop since they have no direct way to load the probeGroup variable themselves, or to reset the probeGroupTask. The only other method would be to manually change the XML file by hand to point to a valid file, and then reopen the workflow.

Let me know what you think, we can discuss on Monday with everyone.