Add identity secrets engine: Entity, EntityAlias, Group and GroupAlias

[stormshield-gt]

This PR is a follow-up of #64 and #38 that include the review feedback plus the missing methods.

It implements all the endpoint for Entity, EntityAlias, Group and GroupAlias

Most of the job is done, it's still a draft because I want to polish the entity::create and group::create with the same tricks I used for entity_alias::create and group_alias::create.

[stormshield-gt]

I've just rebased on master to get the latest changes, this is ready for further review

[Haennetz]

Some cosmetic stuff and typo fixes functionality looks good. Nice work! 👍

[Haennetz]

Also, pleas remove the extra API function exec_with_result_or_empty.
I think the entity and group endpoints do the following.
When the request to the create function includes an id vault send it to the update function which then returns an HTTP response with the return code 204 No Content that's the reason it returns sometime an empty body.

I came up with 2 options to solve this:

1. check if the create function is called with an opts that includes an id and return an error that mentions that the update_by_id should be used.
2. Remove the ID from the create request and explain that the update request should be used.

Let me know what you are thinking about the solution.

[Haennetz]

I thought about the issue with the empty response again, and I came up with that solution to solve this.
Let me know what you think about it.

[stormshield-gt]

Thanks for taking time to review this! I think the suggested solution to the "maybe empty result" problem is fine, I would like to suggest another alternative before I go to implement it.

Maybe we can just remove the id field of CreateEntityRequest and CreateGroupRequest?

The main advantage of this is that we could then return directly a CreateEntityResponse without the Option.
I think the "create" use case of the endpoint is the one we should be favored, so removing the Option should make life easier for users most of the time. The 2 previous PR were going with this direction, so I suppose that's what they wanted.
It also prevents errors at compile time, making it impossible to use it on "update" mode and needing a special logic inside the calling function.
Besides, in the suggested changes, the endpoint reached can be different from the one from the doc, which can be surprising.

This does have the disadvantage to not be conformed to the create entity/group official doc, as we won't support updating through this method. But as long as we make it clear that the user should directly use the update method, I think it's fine.

Anyway, that's just a suggestion, and I'm totally fine going with the proposed solution. Please let me know what you think about this.

[Haennetz]

Thanks for your suggestion i think it is a beeter way.
Maybe you can mention the reason why we removed the id from the create requests and point the users to the Update request if they want to use the id.