BUG: `date_range` `inclusive` parameter behavior doesn't match interval notation
- [X] closes #55293 
- [X] closes #46331

- [X] Added an entry in the latest `doc/source/whatsnew/v2.1.3.rst` file if fixing a bug or adding a new feature.

This pr fixes the issues with `inclusive` in `date_range`

Got rid of the problematic expression which seems to be `i8values[] == start/end_i8`, also the `and` in line 498 should have been an `or`. However after those fixes the if-statement was over complicated, so I simplified it. 
This pull request is stale because it has been open for thirty days with no activity. Please [update](https://pandas.pydata.org/pandas-docs/stable/development/contributing.html#updating-your-pull-request) and respond to this comment if you're still interested in working on this. This pr is ready for review > In this case the test seems a bit cumbersome, was it asserting cases with the behavior we consider a bug in this PR?

Yes, as far as I could tell the tests had a few mistakes in them, also they were written in a really strange and unnecessarily complex way. 
For example this line:
```python
expected = date_range(bday_start, bday_end, freq="D")
```  
should get the expected range, but the `inclusive` argument is not passed to it
 Thanks for the feedback and the work on this @PiotrekB416 

Marco will be able to provide better feedback when he has the time to review, but what makes sense to me is:

- Leave the existing tests as they are in this PR
- Add a clearer brand new test that hits the specific bug you are fixing. If it makes sense we can test more on it
- Only if there is any specific part of the existing tests that fail after your changes, remove that part, in a ver controlled way of what's the behavior we were testing to be true, that we now want to be changed
- In a follow up, we can do a proper refactoring of the tests of this functionality

While what you are doing here seems reasonable, it feels strange that the complex logic you are making much simpler here wasn't implemented for a reason, and that we may be missing some use case where your changes fix a bug, but introduce a new one. Changing too much here makes difficult to see if that will be the case. I feel like the approach I'm proposing should minimize the chances of it happening. What do you think? Thanks for the pull request, but it appears to have gone stale. If interested in continuing, please merge in the main branch, address any review comments and/or failing tests, and we can reopen.