Feature: Support for independent releases in monorepo

# Problem:
We have a monorepo with multiple projects inside of it. These projects are completely unrelated with each other. We have workflows to tag and release these projects but these workflows only run when there is push to certain folder in the monorepo. For example say we have `project1/` and `project2/` folders in the monorepo, we can have this workflow to tag and release project1:
```
name: Tag and release Project1

on:
push:
branches:
- main
paths:
- "project1/**"

jobs:
create-tag-and-release:
name: Tag and release component
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- name: Bump version and push tag
id: tag_version
uses: mathieudutour/github-tag-action@v6.1
with:
github_token: ${{ secrets.GITHUB_TOKEN }}
tag_prefix: project1-v
- name: Create a GitHub release
uses: ncipollo/release-action@v1
with:
tag: ${{ steps.tag_version.outputs.new_tag }}
name: Release ${{ steps.tag_version.outputs.new_tag }}
body: ${{ steps.tag_version.outputs.changelog }}
```

And a similar workflow for project2 just replacing anywhere it says `project1` with `project2`. This works great, especially since the tag_prefix can figure out the correct release and bump based on that. The problem is all commits in the repo are used to make the release even if they are unrelated. So if we:
1. push commit changing files in `project1` folder with "feat:" flag -> only project1 workflow runs -> new release for project1 will have minor version upgrade
2. push commit changing files in `project2` folder with "fix:" flag -> only project2 workflow runs -> new release for project2 will have minor version upgrade since it is reading all the commits since the last release. The commit that was used to trigger the project1 workflow / release is also used here to determine version.

# One possible solution (view comments for better possible solution with paths):
We have a strict github merge structure on the monorepos where all PRs are squashed and merged into main as 1 commit. Ideally, if there could be a flag to not view all commits since the last release, but only view the current commit to figure out the proper bump, it would solve our problem. We could have different releases in our monorepo that are not affected by each other

Start at the GitHub Action's tag and version calculation entry point and trace how the last release and commit range are selected. Reproduce the two path-filtered workflows described in the issue, then verify that each project's release considers only its relevant current change and applies the correct semantic-version bump.

Written by the indexing model from the issue text.