Updated examples get_profile and create_posts in line with new API

[clockworkpc]

The current examples use the /me endpoint and try to identify the profile by the following URN string:
f"urn:li:person:{me_response.entity['id']}.

However, I found that even though I have a valid 3-legged-token with the necessary scopes enabled, I was getting an error.

I believe that the most recent changes to the LinkedIn API require the following changes:

1. /userinfo GET endpoint instead of /me
2. me_response.entity['sub'] instead of me_response.entity['id']

There are some further differences in the names of the fields returned by the userinfo and me endpoints, which are reflected in the proposed changes in the example get_profile.py.

[clockworkpc]

I also wrote a tidier script that focuses on the new API:
https://gist.github.com/clockworkpc/c311d4aea82d8b5adc27bbb6382455ee

[ZLeventer]

The /me → /userinfo migration in the examples is correct and needed. A few specific notes:

1. entity['id'] → entity['sub'] — Right. The /userinfo endpoint returns an OpenID Connect claims set where the user identifier is sub, not id. This is per the OIDC spec (RFC 7519).

2. Variable renaming (response → response_basic, response_field_projects, response_display_image) — Good change for the examples. Reusing response across sequential calls is fine in scripts but confusing in documentation that people read linearly.

3. Field projections update — The new fields (sub, email_verified, name, locale, given_name, family_name, email, picture) match the standard OpenID Connect claims. The old fields (id, firstName:(localized), lastName) were LinkedIn-specific and no longer available on the new endpoint.

I addressed the same /me deprecation in the examples in PR #73 — our changes overlap. Happy to coordinate if the maintainers want to merge one over the other.