TST: Added test case for DataFrame.at
- [x] closes #33544
- [x] tests added
- [x] passes `black pandas`
- [x] passes `git diff upstream/master -u -- "*.py" | flake8 --diff`
- [ ] whatsnew entry

@simonjayhawkins brings up a good point. This is possibly not fully fixed as the expected dtype should not be object but `datetime64[ns, UTC]`.

Interested in fixing this bug @EdAbati?  Hi @mroeschke and @simonjayhawkins ,

I could try to to give it a go, but I am not super familiar with every internal class and I may need some guidance/a little bit more time.

I have tried to debug the `__setitem__` during `result.at[0, "foo"] = datetime(2000, 1, 2, tzinfo=timezone.utc)`. 
I have noticed that at some point it is checked if the timezones are the same/compatible.
In the specific example of the test, even if the tz are not the same/compatible (one is `None` and the other is 'UTC'), it does not raise the TypeError [here](https://github.com/pandas-dev/pandas/blob/b630cdbc33c6e766cc1bfec857b44b04e9db08f8/pandas/core/arrays/datetimes.py#L644) because TypeError is part of a exception statement.

The item is set using `iLocIndexer` and the function `find_common_type` ([link](https://github.com/pandas-dev/pandas/blob/0570237c663434e09fed5bc61712ead07bb14692/pandas/core/dtypes/cast.py#L1425)) is used to translate the dtype to `object`.

What do you think, would changing `find_common_type` be a good approach in this case?
Or would it be better to raise an error for the timezones mismatch?
 I think that behavior is working as expected. The odd part is that essentially the entire column is being changed, so I am not sure why we need to do this data type check. thanks, `.at` like `.loc` does not do coercing of the entire column, unlike `[]` which does. my take-away for this is that the behaviour reported in original issue was perhaps the correct behaviour.

The loss of the timezone a result of the scalar being coerced. This is similar to #22740. Agreed in both cases the user 'incorrectly' expected a different behaviour, because the scalar could be coerced.
For this case, numpy will raise an error in the future and would therefore raise. This will be consistent with https://github.com/pandas-dev/pandas/pull/33577#discussion_r410415299

```
>>> df = pd.DataFrame({"foo": [dt.datetime(2000, 1, 1)]})
>>> df.foo
0   2000-01-01
Name: foo, dtype: datetime64[ns]
>>>
>>> df.foo.dtype.type(dt.datetime(2000, 1, 2, tzinfo=dt.timezone.utc))
<stdin>:1: DeprecationWarning: parsing timezone aware datetimes is deprecated; this will raise an error in the future
numpy.datetime64('2000-01-02T00:00:00.000000')
>>>
```

The 'fixed' issue now coerces the entire column from `datetime64[ns]` to `object`. This is an incorrect behaviour for `.at` IMO