Add custom type handling for collection elements and object attribute types (#9)

* Incorporating usage of spec element type

* Adding tests for custom types on elements

* Updating ci-go.yml to use token for pulling modules from codegen-spec (private repo)

* Linting

* Using latest version of main and calling spec.Parse for validation and spec generation

* Switching to using HasImport available in spec

* Add handling of element type and attribute type into provider and resource

* Add handling of default and plan modifier imports into resources

* Switching to using HasImport() helper method

* Removing unused function

* Wiring-up addition of imports into schema template for provider and resources

* Removing unneeded schemaImport inclusion in import generation as the import is included in the top-level schema.gotmpl

* Moving commands to separate directory

* Adding new line when object contains more than one attribute type

* Adding copyright headers

* Handling custom type in schema generation for collection elements and object attribute types

* Amending golangci configuration to skip output directory

* Refactoring to used shared functions for spec schema ElementType and ObjectAttributeType

* Updating package names to match module name

* Removing unneeded import from schema.gotmpl for data source, provider and resource

* Adding nil check in template for custom field in plan modifier

* Adding nil check in template for custom field in validator

* DRYing up usage of WriteString()

* Adding comment about the usage specschema types

* Using string quoting within fmt.Sprintf()

Author: bendbennett

.golangci.yml

@@ -26,4 +26,6 @@ linters:
 
 run:
   # Prevent false positive timeouts in CI
-  timeout: 5m
+  timeout: 5m
+  skip-dirs:
+    - output

README.md

@@ -8,15 +8,15 @@ facilitate the chaining together of CLI commands.
 The following is a contrived example:
 
 ```shell
-cat examples/ir.json | go run . schema
+cat examples/ir.json | go run . all
 ```
 
 An alternative is to use the `-input` flag to specify a file from which the IR can be read.
 
 For example:
 
 ```shell
-go run . schema -input examples/ir.json
+go run . all -input examples/ir.json
 ```
 
 Both cases will process `ir.json`.
@@ -51,27 +51,6 @@ The general flow is as follows:
 * Write the formatted Go code, one file per data source, provider or resource, into
   `generator/output`.
 
-Currently, the only command that has been implemented is `schema`. This is a bit of a misnomer 
-as the `schema` command generates schema, models and model helper functions but _only_ for data
-sources currently.
-
-## Further Considerations
-
-### Input
-
-* Do we want to have the default for input for both the IR and the IR schema be stdin?
-
-### Validate
-
-* Do we want to improve the detail of the error messages that are generated when the IR is
-  not valid JSON or is this considered outside the scope of the IR2FCG?
-
-### Generate
-
-* Go code generation is leveraging [text/template](https://pkg.go.dev/text/template). Currently,
-  testing of the code generation is using files which contain a textual representation of the 
-  expected generated code. This is quite difficult to visually inspect as no syntax highlighting
-  is provided by an IDE. Perhaps there's a better/easier way to handle this process?
-* The templates that are used for generating Go code are `*.gotmpl` files which do not benefit 
-  from Go syntax highlighting via an IDE. Again, perhaps there's a better/easier way to deal
-  with the templates.
+Currently, the only command that has been implemented is `all`. This is a bit of a misnomer 
+as the `all` command only generates schema for data sources, provider and resources at 
+present.