[breaking change detector] optimization for changelog about renaming breakings

[msyyc]

If SDK API changes from common API to Lro API, there will be begin_ prefix added like:

It is very common kind of breakings, then old breaking tool will detect it in specific

azure-sdk-for-python/tools/azure-sdk-tools/packaging_tools/change_log.py

Lines 186 to 189 in 77b15b5

	new_function = f'begin_{old_function}'
	if f'{op}.{new_function}' in self.added_operations:
	self.added_operations.remove(f'{op}.{new_function}')
	self.breaking_changes.append(_RENAME_OPERATION.format(op, old_function, op, new_function))

so that the changelog is more user-friendly like:

Renamed operation MonitorsOperations.update to MonitorsOperations.begin_update

I hope new tool could also have similar optimization for SDK users.

[catalinaperalta]

The old tool made a guess of when these methods were renamed...if we do this again you have to be aware that the reporting could become inaccurate in some case and then the changelog would have to be manually updated. This one is all about trade-offs...do we prefer to try to have 1 optimized message that could be inaccurate at times? Or do we want to have the 2 entries in the changelog which are still accurate but more verbose?

[catalinaperalta]

One more thing, if we cant make a good approximation of when a method was renamed we may still have 2 entries in the changelog.

[msyyc]

Since the naming pattern change for non-lro to lro is fixed (both for DPG and MPG) and the logic is not complicated, I think it is worth to do.
At least for MPG, I prefer 1 optimized message.

[msyyc]

One more thing, if we cant make a good approximation of when a method was renamed we may still have 2 entries in the changelog.

Sure, this issue is mainly for begin_ pattern, not including other scenarios.