TECHNICAL FIELD [0001] The subject specification relates generally to memory management in computer systems and more particularly, to a system and methodology that facilitates automated object lifetime management. BACKGROUND [0002] As computer science has evolved, object oriented programming has become one of many familiar models employed by designers and programmers to implement functionality within computer systems. The object model can comprise of one or more objects that act on each other, as opposed to a traditional model that comprises of programs that are a collection of functions, or simply a list of instructions. Each object is capable of receiving messages, processing data, sending messages to other objects and can be viewed as an independent machine with a distinct role or responsibility. [0003] The object lifetime (or life cycle) of an object, in object-oriented programming, is the time between an object's creation (also known as instantiation or construction) and an object's destruction. An object can be created and/or destroyed automatically (such as a managed object) or manually (such as a native or unmanaged object). Managed objects may be described in terms of a data type (e.g., metadata) and automatically collected (e.g., reclaimed) by a managed environment such as a garbage collector that removes the object fi-om memory when the object is no longer being accessed. In contrast, unmanaged objects can be allocated from a standard operating system heap, wherein the object itself is responsible for freeing memory it employs when references to the object no longer exist. This can be accomplished through vi^ell-known techniques such as reference counting, for example. [0004] As described above, managed objects can be allocated from a managed heap and automatically garbage collected. In order to achieve this, references to managed objects can be traced. When a last reference to sm object is removed, the garbage collector can reclaim the memory occupied by the object, mitigating the need to reference count managed objects. Tracing is possible within managed code because the managed environment can keep frack of outstanding references that exist on an object. As each new object reference is declared within managed code, the managed environment can add the reference to a list of live references. At any given time, the managed environment, rather than the object itself, can thus be aware of live references that exist on a given object. As references fall out of scope or change value, the list of live references can be updated, and as long as a reference remains within managed code, the managed environment can trace it. [0005] The implementation of an object can be split across a native part and a managed part (peers). The native peer's lifetime can be controlled with a reference counting technique whereas the garbage collector, as discussed above, can manage the managed peer's lifetime. When some of the references between managed objects go through native code, the managed objects can be leaked or pre-maturely collected. [0006] In multiple managed/native object pair scenarios, as long as a reference to either of the objects exists, the pair must live. Traditional solutions require multiple garbage collections to reclaim the objects and are prone to memory leaks, wherein the objects do not get collected even though there are no external references to the objects, and premature collection, wherein the garbage collector reclaims the objects even though an unmanaged reference may exist. SUMMARY [0007] The following presents a simplified summary of the specification in order to provide a basic understanding of some aspects of the specification. This summary is not an extensive overview of the specification. It is intended to neither identify key or critical elements of the specification nor delineate the scope of the specification. Its sole purpose is to present some concepts of the specification in a simplified form as a prelude to the more detailed description that is presented later. [0008] The system disclosed and claimed herein, in one aspect thereof, facilitates management of the lifetime of an object. The system allows transitioning between object lifetime management systems on the native side, such as a reference counting system, and on the managed side, such as a garbage collection system. In certain phases, the system employs the reference counting system to control lifetime of an object pair whereas in other phases the system turns the lifetime control over to the garbage collection system, in a manner that is transparent to the programmer and/or end user. The system can determine lifetime of an object by dynamically switching between two lifetime management systems based on an analysis of references (direct or indirect) to the object. [0009] According to an aspect of the system, a reference counting component employs a reference counting technique to calculate the references on each object. The reference counting component determines the total number of references on each native object peer and accordingly assigns a reference count to each native object peer. An analysis component analyzes references on a native object. In addition, the analysis component weakens and/or strengthens the references between object peers based on the analysis to avoid memory leaks. A weak reference is a reference to a managed object that does not prevent the managed object from being garbage collected such that a managed object is collectable if there are no sfrong references to it. Furthermore, once references are weakened, the analysis component duplicates intra native references to the managed side based on the reference analysis and prevents premature collection. The analysis component can facilitate the transitioning of lifetime management from a reference counting system to a garbage collection system and back. [0010] According to yet another aispect of the system, when external references do not exist on the native side in multiple object pairs, the references from a native peer to a managed peer are weakened. Wealcening references to managed peers within a sub tree allows the managed peers to be collected when managed references to the peers are dropped/removed. Once the references to the managed peers are weakened, the system clones the native references to the managed side and avoids premature collection. If a new external (direct and/or indirect) native reference is made to a native peer, the references to managed peers within the sub free are made strong again. [0011] One aspect of the system relates to an optimization component that is employed to release references between managed and native peers and/or suppress SafeHandles from finalization. Typically, a SafeHandle is a managed object that holds a reference to a native object. When managed objects are collected, a finalization mechanism is employed that performs final processing during garbage collection of a managed object. When the SafeHandle is garbage collected, its finalization step releases its reference on the native peer .The optimization component described leverages the domain specific properties of the system to derive a set of static rules for deciding when to sfrengthen/weaken references. Furthermore, in accordance with an Jispect of the system, if a managed peer carries no state, the optimization component keeps a weak reference on it. [0012] Yet another aspect of the vSystem relates to a pending remove list for references that is employed to avoid race conditions. When a managed peer is garbage collected, a reference to weak reference object is kept in a pending remove list imtil a SafeHandle for that peer is finalized. An object can be finalized at any point in time after it has been collected. This allows the managed peer to be recreated if necessary before the finalizer has run. [0013] The following description and the annexed drawings set forth certain illusfrative aspects of the specification. These aspects are indicative, however, of but a few of the various ways in which the principles of the specification may be employed. Other advantages and novel features of the specification will become apparent from the following detailed description of the specification when considered in conjunction with the drawings. BRIEF DESCRIPTION OF THE DRAWINGS [0014] FIG. 1 illustrates a block diagram of an exemplary system that facilitates object lifetime management. [0015] FIG. 2 illustrates an exemplary scenario wherein an object is split between a managed side and a native side according to one aspect of the specification. [0016] FIG. 3 illustrates an exemplary scenario wherein references to a managed peer are weakened according to an aspect of the specification. [0017] FIG. 4A- 4D illustrate an exemplary garbage collection mechanism for multiple object pairs. [0018] FIG. 5 A-B illustrate an ex