fix: use organization_id smarter

[badass-aoz]

Summary

While working on #74 I noticed that organization_id isn't consistently set, so I went through all the example files and ensured it's used in a consistent way. In details:

1. if organization_id is not provided, we try to derive it w/ the provider project_id
2. we fail to do that, we warn users
3. in places where organization_id is used, we consistently use the derived local.organization_id instead of user-provided var.organization_id.

I also updated the min version requirements because minimum TF 1.5 is needed to support checks block. This makes it consistent w/ the Azure TF repo.

How did you test this change?

1. Go through all example main.tf, add a valid provider project_id, and observe terraform apply goes through.
2. Remove project_id and observe checks kick in

Issue

https://lacework.atlassian.net/browse/LINK-2695

[badass-aoz]

I think this will make the logic here less convoluted. Previously there's an implicit dependency:

• local.scanning_project_id depends on data.google_project.selected depends on var.organization_id

which made things a bit hard to reason about. Hence I'm doing this cleanup, so we'll always try to get the current project regardless whether organization_id is provided. LMK if this condition is actually needed.

[selvats]

@badass-aoz, there is feedback in https://lacework.slack.com/archives/C03H3863SQG/p1714591554167629 on the version for the google provider. Can it also be addressed in this PR?