Add OnePhotonSeries

[CodyCBakerPhD]

WIP following the discussion of #283

Summary of changes

• Add OnePhotonSeries

Checklist

For all schema changes:

• Add release notes for the PR to docs/format/source/format_release_notes.rst.

If this is the first schema change after a schema release (i.e., the version string in core/nwb.namespace.yaml does not
end in "-alpha"), then:

• Update the version string in core/nwb.namespace.yaml and core/nwb.file.yaml to the next major/minor/patch
  version with the suffix "-alpha". For example, if the current version is 2.4.0 and this is a minor change, then the
  new version string should be "2.5.0-alpha".
• Update the value of the version variable in docs/format/source/conf.py to the next version without the
  suffix "-alpha", e.g., "2.5.0".
• Update the value of the release variable in docs/format/source/conf.py to the next version with the suffix
  "-alpha", e.g., "2.5.0-alpha".
• Add a new section in the release notes docs/format/source/format_release_notes.rst for the new version
  with the date "Upcoming" in parentheses.

Resolves #283

[CodyCBakerPhD]

Splitting this PR, which introduces the basic OnePhotonSeries object that has some extra optional fields the TwoPhotonSeries does not, with the rest of the discussion from #283 which focused on all the types of custom device metadata that might be needed if someone does not specify the manufacturer/model number (in the case of custom builds). I've stashed work on that kind of thing, though: https://github.com/catalystneuro/nwb-schema/tree/custom_optical_imaging_device

In the end, I think adding enhanced support for custom Devices like this is a separate topic from adding support for OnePhoton data itself, which is largely just a minor consideration of the differences with the TwoPhoton data.

It's also my opinion that going down the road of thoroughly documenting every possible custom device configuration parameter is so open-ended and dynamic that we should either only support free-form text (which is already supported by the description of any Device) for specifying as many of these details as the user wishes, or encourage the development of extensions for specific sub-types of devices. But I'm open to discussion on this, so I'll bring it up at the next meeting.

[CodyCBakerPhD]

@oruebel @rly @bendichter Met with @DaveOC90 today who confirmed this new object captures and describes all the necessary components of their experiments.

PR is now ready for review.

[oruebel]

Overall the schema looks good to me. I just had a couple of minor questions/comments.

[oruebel]

Looks good to me. We should ideally also get approval from @bendichter and @rly

[CodyCBakerPhD]

@oruebel @bendichter Are we good to merge this?

[CodyCBakerPhD]

Field of view removed

[rly]

Looks good. Please add and test a PyNWB API for this before we merge. This looks like a relatively simple data type. I wonder whether the get_class for this type in PyNWB is sufficient.

[bendichter]

@CodyCBakerPhD I believe this would be a minor change, since it does not break backwards compatibility. Could you please update the changelog accordingly?

[CodyCBakerPhD]

@bendichter Done, also included the subject attribute addition with it since they are 'new features added in a back-compatible manner'

[oruebel]

one, also included the subject attribute addition

Where is this included here?

[CodyCBakerPhD]

Where is this included here?

In the changelog sectioning: https://github.com/NeurodataWithoutBorders/nwb-schema/pull/523/files#diff-9223a9a6538334955ca2145d2b76549cdebe59e8842243d6fd74518c43ae9016L6-R14