Set run_exports max_pin to x.x for 1.10.3

[jdblischak]

Checklist

• Used a personal fork of the feedstock to propose changes
• Bumped the build number (if the version is unchanged)
• Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
• Ensured the license file is being packaged.

Follow up to #11. It's not sufficient to bump the max_pin for 1.11.0. That only prevents future problems. The tiledb recipe is pinned to build with 1.10.3 (conda-forge/tiledb-feedstock#229), but since it's run exports wasn't updated, the recently built 2.19.1 (conda-forge/tiledb-feedstock#233) can be co-installed with azure-core-cpp 1.11, which once again generates the segfault (conda-forge/tiledb-feedstock#228 (comment))

My patch (conda-forge/conda-forge-repodata-patches-feedstock#639) didn't catch this because patches have to have time limits (which makes sense, otherwise it's hard to evaluate how they will affect the metadata of future packages). After this PR is merged, I'll submit a follow up patch that will fix the current situation.

[conda-forge-webservices]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

[jdblischak]

Also for transparency here is how I created the backport branch for 1.10.3:

git checkout 26509264adc740441ba8c1e09f0a62fd9f2b4f38
git checkout -b 1.10.3
git log -n 1 --oneline
## 2650926 (HEAD -> 1.10.3) azure-core-cpp v1.10.3 (#7)
git push upstream 1.10.3

[github-actions]

Hi! This is the friendly conda-forge automerge bot!

I considered the following status checks when analyzing this PR:

• linter: passed
• azure: passed

Thus the PR was passing and merged! Have a great day!