Added improvements in to_datetime Error reporting message
- This PR aims to close 3 related issues - 
#16757 , 
#46509 , 
#47495

- Changes description
    -  For issue #16757 - added more details in error message about field and its position causing the issue in `pandas/_libs/tslib.pyx` in `_array_to_datetime_object` and `array_to_datetime`
    -  For issue #46509 -  added more details in OutOfBoundsDatetime exception about field and its position causing the issue in `pandas/_libs/tslib.pyx` in `array_to_datetime`
    - For issue #47495 - made change in `pandas/_libs/tslibs/parsing.pyx` to accept "now" and "today" values. These values are accepted in other parts of parsing ( `_parse_today_now` in `pandas/_libs/tslib.pyx` ) but when `pd.to_datetime` is supplied with an list having an error value(eg - `pd.to_datetime(["today", "yesterday"])` ), the parsing done post raised exception in `parse_datetime_string` in `pandas/_libs/tslibs/parsing.pyx` does not accept "now" and "today", hence the wrong element is shown in the error

- Examples of changed error messages


    | Code       | Old Error ( on 1.4.3 ) | New Error |
    | ------------- | ------------- | ------------- |
    | pd.to_datetime(pd.Series(['2016-01-01', 'unparseable']), errors='raise')  | dateutil.parser._parser.ParserError: Unknown string format: unparseable  | ValueError: Unable to parse string "unparseable" at position 1 |
    | pd.to_datetime(pd.Series(['2016-01-01', 'unparseable']), format='%Y-%m-%d', errors='raise') | ValueError: time data unparseable doesn't match format specified  | ValueError: time data "unparseable" at position 1 doesn't match format specified |
    | pd.to_datetime(pd.Series(['2016-01-01', '12']), errors='raise') | ValueError: Given date string not likely a datetime.  | ValueError: Unable to parse string "12" at position 1 |
    | pd.to_datetime('11:0') | pandas._libs.tslibs.np_datetime.OutOfBoundsDatetime: Out of bounds nanosecond timestamp: 1-01-01 11:00:00  | pandas._libs.tslibs.np_datetime.OutOfBoundsDatetime: Cannot convert "11:0" at position 0 to datetime |
    | pd.to_datetime(["today", "yesterday"]) | dateutil.parser._parser.ParserError: Unknown string format: today  | ValueError: Unable to parse string "yesterday" at position 1 |

**To Do**
- [ ] add testcases covering above errors once given the initial go ahead. ( am bit new here, was thinking of sending the changes in chunks, instead of going more ahead in wrong direction 🙂  )

Thanks for the PR @dannyi96. Can you review the tests please? We usually test for error messages, and those tests are probably failing. Also, can you add a note to the release notes about this? Thank you! For `Given date string not likely a datetime.`, I think it would be better to change the message where it was raised instead of raising a new exceptions with a new message. > Thanks for the PR @dannyi96. Can you review the tests please? We usually test for error messages, and those tests are probably failing. Also, can you add a note to the release notes about this? Thank you!
thanks @datapythonista, sure will add this change
 > For `Given date string not likely a datetime.`, I think it would be better to change the message where it was raised instead of raising a new exceptions with a new message.

sure thing @mroeschke , one quick question here - 
the method which generates this exception doesn't have the context of the index/position, so should we consider
1. just leaving it to be a basic exception message change to `f'Given date string {date_string} not likely a datetime.'` and propagate this exception
2. Pass the index information to this method (as a new parameter ) so we can generate clearer message `f'Given date string {date_string} at position {index} not likely a datetime.'` and propagate this exception
3. (current approach) regenerate new exception post above thrown exception to add in the index related info.


 > > For `Given date string not likely a datetime.`, I think it would be better to change the message where it was raised instead of raising a new exceptions with a new message.
> 
> sure thing @mroeschke , one quick question here - the method which generates this exception doesn't have the context of the index/position, so should we consider
> 
>     1. just leaving it to be a basic exception message change to `f'Given date string {date_string} not likely a datetime.'` and propagate this exception
> 
>     2. Pass the index information to this method (as a new parameter ) so we can generate clearer message `f'Given date string {date_string} at position {index} not likely a datetime.'` and propagate this exception
> 
>     3. (current approach) regenerate new exception post above thrown exception to add in the index related info.

I think keeping it simple with option 1 is good for now sure thing @mroeschke. that would indeed be better.
Will work on splitting the PRs. > sure thing @mroeschke. that would indeed be better. Will work on splitting the PRs.

Thanks for your effort here so far @dannyi96. I'm supportive of the changes here generally. We just need to be a little mindful of exceptions in this part of the code base since there's a lot of "fall back" behavior triggered by exceptions. 
> Thanks for your effort here so far @dannyi96. I'm supportive of the changes here generally. We just need to be a little mindful of exceptions in this part of the code base since there's a lot of "fall back" behavior triggered by exceptions.

thanks @mroeschke for the guidance/support 🙂 
yes, looks like we need to be bit more careful in this portion of code. am closing this as the three issues are being addressed in 3 separate PRs - 
#16757 - #47995, 
#46509 - #47849, 
#47495 - #47860 