TypeExtensions.GetOpenApiReferenceId does not support generics more than 1 level deep

**Describe the issue**
When declaring objects using generics that go more than one levels deep, the `GetOpenApiReferenceId` method will generate the same id, no matter what the inner classes are, due to the logic [here](https://github.com/Azure/azure-functions-openapi-extension/blob/877a1db3294995fba1a7b233e6e5d14b87b6570a/src/Microsoft.Azure.WebJobs.Extensions.OpenApi.Core/Extensions/TypeExtensions.cs#L416).

This will result in that all the instances where the outer classes are the same, only one schema will be used in the resulting documentation.

**To Reproduce**
Assume that we have a common response model
```
class ResponseModel {
public T data {get; set;}
}
```
And two classes we want to respond with
```
class Foo {}

class Bar {}
```
And two functions with the following attributes
```
[OpenApiResponseWithBody(
statusCode: HttpStatusCode.OK,
contentType: MediaTypeNames.Application.Json,
bodyType: typeof(ResponseModel>)
)]
```
and
```
[OpenApiResponseWithBody(
statusCode: HttpStatusCode.OK,
contentType: MediaTypeNames.Application.Json,
bodyType: typeof(ResponseModel>)
)]
```
This will result in `ResponseModel>` (if processed first) being used for documenting the response body of both functions

**Expected behavior**
`ResponseModel>` for documenting the first function and `ResponseModel>` for documenting the second one.

Start in src/Microsoft.Azure.WebJobs.Extensions.OpenApi.Core/Extensions/TypeExtensions.cs at GetOpenApiReferenceId and inspect the linked generic-type logic. Reproduce the ResponseModel> and ResponseModel> example, then verify that each nested generic type produces its own schema reference and the corresponding function documentation uses the correct model.

Written by the indexing model from the issue text.