ENH: support nanoseconds in Period constructor

[arw2019]

• closes BUG: Period constructor does not take into account nanonseconds #34621
• closes BUG: Period with nanoseconds (?) #17053
• tests added / passed
• passes black pandas
• passes git diff upstream/master -u -- "*.py" | flake8 --diff
• whatsnew entry

Picking up #34720

ASVs:

asv continuous -f 1.1 upstream/master HEAD -b ^period

       before           after         ratio
     [3f510600]       [2b2f1d04]
     <GH34621-nanos-for-Period^2>       <GH34621-nanos-for-Period>
+      7.46±0.2ms       11.6±0.1ms     1.55  period.PeriodIndexConstructor.time_from_ints('D', False)
+      7.57±0.3ms      11.4±0.03ms     1.51  period.PeriodIndexConstructor.time_from_ints('D', True)
+      52.8±0.6ms       59.2±0.4ms     1.12  period.PeriodIndexConstructor.time_from_ints_daily('D', True)
+      52.9±0.9ms       59.0±0.1ms     1.11  period.PeriodIndexConstructor.time_from_ints_daily('D', False)
-      3.21±0.2μs      2.90±0.02μs     0.90  period.Indexing.time_get_loc

SOME BENCHMARKS HAVE CHANGED SIGNIFICANTLY.
PERFORMANCE DECREASED. 

cc @jreback #34720 (comment) in case we want this for 1.2

[jreback]

lgtm. can you add a whatsnew in bug fixes for 1.2

cc @jbrockmendel

[jreback]

thanks @arw2019

[jorisvandenbossche]

Aren't we effectively doing the parsing twice, this way? (once in parse_time_string, once in Timestamp) Any way to avoid this?

[arw2019]

Yes - @jreback suggested integrating this a bit more into parse_time_string

I opened #38312 to track resolution (I'll have a go at it if no one else does)

[jorisvandenbossche]

Thanks!