Add account entity class and its service class along with a configuration to the database connection

[naz-hage]

The account entity class and its service class is the first class which contains the properties of an account of a financial institution.
Acceptance Criteria:

1. Decide on a location for the database: This is a crucial step defining the configuration of your database connection.

2. Add capability to create, update, delete an account: This is in a repository or service class, not directly in the entity class. The entity class just represents the structure of the data.

3. Add attributes for input validation: This can be done in the entity class using data annotations. For example, you can use [Required], [StringLength], etc. to enforce certain constraints.

4. Add unit tests to validate create, update, or delete an account: This is a good practice to ensure your code is working as expected.

5. Document the account entity properties and provide an example how to make calls: This includes comments in the code explaining what each property is for, as well as higher-level documentation showing how to use your classes to interact with the database.

• Follow these guidelines for the class
  1. Class Declaration: The class should be public and not sealed or abstract.
  2. Properties: It should have properties representing the columns of the table in the database. Each property should have a public getter and setter.
  3. Primary Key: At least one property should be marked with the [Key] attribute to represent the primary key of the table.
  4. Data Annotations: If necessary, properties should be decorated with data annotations for validation and to define relationships between tables (like [Required], [StringLength], [ForeignKey], etc.).
  5. Navigation Properties: If there are relationships with other tables, these should be represented as navigation properties in the class.
  6. Constructor: If necessary, a parameterless constructor should be present. This is required for the Entity Framework to create an instance of the class.

Here is an example of a complete entity class for a Product table:

using System.ComponentModel.DataAnnotations;
using System.ComponentModel.DataAnnotations.Schema;

public class Product
{
    [Key]
    public int ProductId { get; set; }

    [Required]
    [StringLength(100)]
    public string Name { get; set; }

    public decimal Price { get; set; }

    [ForeignKey("CategoryId")]
    public virtual Category Category { get; set; }
}

Since we are using SQLite, there are some limitations to keep in mind:

1. Limited Data Types: SQLite has a more limited set of data types than some other databases. For example, there's no separate boolean type. Booleans are stored as integers 0 (false) and 1 (true).
2. Case Sensitivity: By default, SQLite is case-insensitive when comparing string values. If you need case-sensitive comparisons, you'll need to configure that at the database level or use a specific SQLite function in your queries.
3. Concurrency: SQLite does not support multiple concurrent writers. If your application requires high levels of write concurrency, SQLite might not be the best choice.
4. Migrations: When using Entity Framework Core migrations, some operations are not supported due to SQLite limitations, such as altering existing columns.

[naz-hage]

@ahmdhjj, I'm trying to keep issues small, managable and focused which correspond to a single pull request.
As I look at this issue, it is going to take more than one pull request to complete the current acceptance criteria as writen. I'll adjust the issue and submit the pull request today. I'm thinking to focuse this issue on creating a simple Record entity instead of the Account Entity, This will give us a chance to learn and iron out the details of adding a new database entity. Let me what you think.