Remove unnecessary iNaT checks from _Period properties
In the status quo, `pd.Period.year` goes through several layers of redirection, one of which checks for `self.ordinal == iNaT`.

```
cdef class _Period(object):
   [...]
    cdef _field(self, alias):
        base, mult = frequencies.get_freq_code(self.freq)
        return get_period_field(alias, self.ordinal, base)

    property year:
        def __get__(self):
            return self._field(0)

[...]
def get_period_field(int code, int64_t value, int freq):
    cdef accessor f = _get_accessor_func(code)
    if f is NULL:
        raise ValueError('Unrecognized period code: %d' % code)
    if value == iNaT:
        return np.nan
    return f(value, freq)
```

But `Period.ordinal` will never be `iNaT`, because `Period.__new__` returns `NaT` in that case instead of a `Period` object.  So we can skip the `value == iNaT` check in `get_period_field`.  With that out of the way, we can skip `_get_accessor_func` and `_field` and and just write in `pyear(ordinal, freq)`.

This PR changes this property lookup for `year`, `month`, `day`, ...

Speedups ~10% across the board.  Before:

```
In [2]: per = pd.Timestamp.now().to_period('M')
In [4]: %timeit per.month
The slowest run took 12.73 times longer than the fastest. This could mean that an intermediate result is being cached.
1000000 loops, best of 3: 1.4 µs per loop

In [5]: %timeit per.second
The slowest run took 15.01 times longer than the fastest. This could mean that an intermediate result is being cached.
1000000 loops, best of 3: 1.4 µs per loop

In [6]: %timeit per.year
The slowest run took 14.73 times longer than the fastest. This could mean that an intermediate result is being cached.
100000 loops, best of 3: 1.36 µs per loop

In [7]: %timeit per.is_leap_year
The slowest run took 16.94 times longer than the fastest. This could mean that an intermediate result is being cached.
1000000 loops, best of 3: 1.37 µs per loop



In [8]: per = pd.Timestamp.now().to_period('ms')

In [9]: %timeit per.is_leap_year
The slowest run took 16.74 times longer than the fastest. This could mean that an intermediate result is being cached.
1000000 loops, best of 3: 1.5 µs per loop

In [10]: %timeit per.minute
The slowest run took 13.71 times longer than the fastest. This could mean that an intermediate result is being cached.
1000000 loops, best of 3: 1.37 µs per loop
```

After:
```
In [2]: per = pd.Timestamp.now().to_period('M')

In [3]: %timeit per.month
The slowest run took 19.96 times longer than the fastest. This could mean that an intermediate result is being cached.
1000000 loops, best of 3: 1.21 µs per loop

In [4]: %timeit per.second
The slowest run took 15.26 times longer than the fastest. This could mean that an intermediate result is being cached.
1000000 loops, best of 3: 1.25 µs per loop

In [5]: %timeit per.year
The slowest run took 16.55 times longer than the fastest. This could mean that an intermediate result is being cached.
1000000 loops, best of 3: 1.21 µs per loop

In [6]: %timeit per.is_leap_year
The slowest run took 15.96 times longer than the fastest. This could mean that an intermediate result is being cached.
1000000 loops, best of 3: 1.24 µs per loop

In [7]: per = pd.Timestamp.now().to_period('ms')

In [8]: %timeit per.is_leap_year
The slowest run took 15.72 times longer than the fastest. This could mean that an intermediate result is being cached.
1000000 loops, best of 3: 1.33 µs per loop

In [9]: %timeit per.minute
The slowest run took 17.03 times longer than the fastest. This could mean that an intermediate result is being cached.
1000000 loops, best of 3: 1.23 µs per loop

```



- [ ] closes #xxxx
- [ ] tests added / passed
- [ ] passes `git diff upstream/master -u -- "*.py" | flake8 --diff`
- [ ] whatsnew entry
